Linux cgroup v2 memory.reclaim 怎样主动回收指定内存

可以把 memory.reclaim 理解为“对指定 cgroup 发起一次主动回收请求”的只写控制文件。它接受目标回收量，也可以通过 swappiness 指定回收倾向；内核实际回收量可能多于或少于请求量，回收不足时会以 EAGAIN 表示。它适合做有边界的内存整理，不应该直接当成内存压力告警。

官方地址：https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

本文只讨论 cgroup v2 的 memory.reclaim，不把它扩展成 OOM 处置、全机缓存回收或网络调优方案。

先确认 memory.reclaim 到底控制什么

memory.reclaim 存在于 cgroup v2 的控制目录中，是一个只写的 nested-keyed 文件。写入目标量后，内核尝试从目标 cgroup 回收可回收内存；这个接口的“目标量”是请求，不是承诺的精确结果。

最容易混淆的是三个概念：

• 目标 cgroup：决定回收范围，不能把任意进程的 PID 当成这个接口的参数。
• 请求量：例如 1G，表示希望回收的数量，不代表一定会释放 1G。
• 主动回收：由这个文件触发，不等同于系统已经检测到 memory pressure。

准备目标 cgroup，并先记录观察值

实际操作前先确定目标目录，而不是直接对系统中某个猜测路径写入。下面的变量只是示例路径，部署时应替换为已经确认的业务 cgroup。

# 指向已经确认的目标 cgroup，不要把 /sys/fs/cgroup 当成业务目录直接操作
cg=/sys/fs/cgroup/demo.slice

# 确认主动回收接口存在；不存在时先检查是否使用了 cgroup v2
test -w "$cg/memory.reclaim" || {
  echo "memory.reclaim 不可写，请检查挂载方式和权限" >&2
  exit 1
}

# 记录当前用量，便于解释回收前后的变化；它不是 memory.reclaim 的返回值
cat "$cg/memory.current"

这里记录 memory.current 是为了建立上下文。不要把它的差值机械地当成“本次回收字节数”，因为目标 cgroup 中的分配、释放和子 cgroup 变化可能同时发生。

按目标量发起一次主动回收

最直接的写法是把带单位的数量写入 memory.reclaim。Linux 内核文档给出的语义是：该接口尝试从目标 cgroup 回收指定数量，但允许实际结果出现偏差。

# 请求目标 cgroup 尝试回收 1 GiB；这里的 1G 是请求量，不是保证值
if ! printf '%s\n' '1G' > "$cg/memory.reclaim"; then
  # 写入失败通常要回到路径、权限、挂载控制器和目标状态排查
  echo "memory.reclaim 写入失败" >&2
  exit 1
fi

# 回收后再次读取用量，只用于观察整体变化
cat "$cg/memory.current"

如果业务需要改变回收倾向，可以使用 nested key。文档定义了 swappiness 参数；例如 swappiness=max 表示只回收匿名内存，具体值仍应结合内核版本、工作负载和现场策略解释。

# 以指定 swappiness 请求回收；参数只影响本次主动回收的选择倾向
printf '%s\n' '512M swappiness=0' > "$cg/memory.reclaim"

# max 是文档定义的特殊值，表示只回收匿名内存；按需选择，不要和默认策略混用
printf '%s\n' '512M swappiness=max' > "$cg/memory.reclaim"

示例中的 swappiness 不是“保证只释放某一类页面”的硬开关。它是回收策略参数，回收结果仍受目标 cgroup 内存组成、可回收程度和内核实现限制影响。

怎样理解回收不足与 EAGAIN

写入成功并不意味着恰好释放了请求量。内核可能回收过量，也可能回收不足；当实际回收少于指定数量时，接口会返回 -EAGAIN。因此排查时应该把“写请求”“内核返回”和“观察值”分开记录。

# 将错误输出单独记录，便于区分回收不足与权限、路径错误
if printf '%s\n' '1G' > "$cg/memory.reclaim" 2>reclaim.err; then
  echo "reclaim 请求已提交"
else
  rc=$?
  # 这里只展示错误分支；生产脚本应保留 rc 和错误文本供上层判断
  echo "reclaim 请求未完成，shell_rc=$rc" >&2
  sed -n '1,3p' reclaim.err >&2
fi

# 再读一次用量，避免只凭 shell 返回状态推断释放了多少内存
cat "$cg/memory.current"

不要把 EAGAIN 改写成“接口坏了”。它更接近“目标量没有完全达到”的边界提示；脚本是否重试，要看这次主动回收是否真的有必要、目标 cgroup 是否仍然存在可回收对象，以及重试是否会干扰业务。

把主动回收与压力指标分开监控

这个接口的另一个关键边界是：由 memory.reclaim 触发的主动回收，不应被直接解释为 memory cgroup 正在承受压力。文档还特别说明，这种回收通常不会触发网络层依据压力进行的自适应平衡。

因此，监控面可以分成两组：一组记录主动回收请求、请求量、返回错误和 memory.current 变化；另一组独立读取 memory.events、memory.pressure 等压力或事件信号。两组数据可以关联分析，但不要把一次主动回收写入当成压力告警本身。

常见误区与适用边界

总结

使用 memory.reclaim 的核心是先锁定目标 cgroup，再把带单位的请求量写入控制文件，并同时保留返回状态和前后观察值。遇到 EAGAIN 时，要解释为“请求量未完全满足”的边界，而不是盲目扩大重试。最后，把主动回收记录与 memory.events、memory.pressure 等压力信号分开，才能避免把维护动作误判为系统压力。

相关问题

• memory.reclaim 可以直接指定 PID 吗？ 不可以，它面向 cgroup 控制目录；需要先把进程归入目标 cgroup，再对该目录操作。
• 为什么回收前后 memory.current 没有明显下降？ 目标内存可能不可回收，或者业务分配与回收同时发生，不能只凭一次读数下结论。
• memory.reclaim 和 OOM 是一回事吗？ 不是，前者是主动回收接口，OOM 是内存不足处理路径，触发条件和结果不同。
• 什么时候不适合主动回收？ 当业务没有明确维护窗口、回收可能引入抖动，或团队没有配套观测与回滚策略时，不应把它当成常规“清内存”按钮。