Linux cgroups v2 怎样让 memory.min 保护递归生效

如果你把 memory.min 当成“给服务预留一块固定内存”，很容易误判 cgroups v2 的行为。它提供的是硬回收保护：在 cgroup 的有效 min 边界内，内存不会被回收；但子 cgroup 的保护仍然受祖先边界约束，父子值相加也不等于主机一定会为它们准备同样多的内存。

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

本文只讨论一个问题：怎样让 memory.min 的保护沿 cgroups v2 层级正确工作，并能读出配置的实际边界。示例是静态说明，命令需要在你自己的 Linux 环境中按权限和发行版配置调整。

先分清 memory.min 保护的对象

memory.min 是非根 cgroup 的可读写接口，默认值为 0。当 cgroup 的用量处在有效 min 边界内，内核不会在回收压力下回收这部分内存；如果没有未保护的可回收内存，压力可能继续传导到 OOM。它不是 memory.max 那种硬上限，也不是 memory.low 那种尽力而为的保护。

判断一组配置时，先沿层级看三件事：父 cgroup 能给出的保护边界、子 cgroup 写入的 memory.min，以及子树实际使用的 memory.current。官方文档还特别说明，memory.current 统计当前 cgroup 及其后代的用量。

父子 cgroup 的有效保护怎样计算

假设 parent 下有 service，service 下又有 worker。即使 worker 写入了较大的 memory.min，它的有效保护仍会被祖先 cgroup 的 memory.min 限制。不能把每一级的数值简单相加后，当作主机必须保护的总量。

当子 cgroup 的保护需求超过父级允许的范围时，内核会根据子 cgroup 在 memory.min 以下的实际内存使用量按比例分配父级保护。换句话说，配置文件里的值是“需求”，有效边界还要结合祖先和实际用量阅读。

# 只读取配置与当前用量，不修改 cgroup 状态
base=/sys/fs/cgroup/my-service
printf 'service min: '
cat "$base/memory.min"
printf 'service current: '
cat "$base/memory.current"

# 子目录的 memory.current 会把子孙 cgroup 的用量纳入统计
for child in "$base"/*; do
  [ -d "$child" ] || continue
  printf '%s min=' "$child"
  cat "$child/memory.min"
  printf '%s current=' "$child"
  cat "$child/memory.current"
done

这段读取逻辑的重点不是把输出相加，而是确认层级：父级保护是否足够、子级当前用量是否已经接近自己的 min，以及同一父级下是否存在多个互相竞争的子树。

怎样让保护沿层级递归应用

cgroups v2 支持 memory_recursiveprot 挂载选项。启用它后，memory.min 和 memory.low 的保护可以递归应用到整个子树，而不要求管理员把保护值逐层向下重复配置。这个选项是系统范围的挂载语义，只能在初始挂载命名空间中设置或重新挂载；容器内部看到的 cgroup 视图不一定拥有这个权限。

先确认当前 cgroup2 挂载点与选项，再由系统管理员决定是否重挂载。不要把下面命令当作所有发行版的通用上线步骤：

# 读取当前 cgroup2 挂载点和选项，先确认实际环境
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS

# 仅示意在初始挂载命名空间重新挂载并加入递归保护选项
# 生产环境应先确认 systemd、容器运行时或启动脚本是否管理该挂载
mount -o remount,memory_recursiveprot /sys/fs/cgroup

如果系统由 systemd 或容器编排器管理 cgroup 层级，优先使用其正式配置入口，避免手工 remount 与服务管理器的状态互相覆盖。这里真正要确认的是“挂载选项是否已生效”和“写入保护的层级是否属于你管理的子树”，而不是只看到某个目录下存在 memory.min 文件。

怎样判断保护是否过度承诺

硬保护的代价是回收空间变少。Linux 内核文档明确提醒：把明显多于一般可用内存的容量置于 memory.min 保护下，可能导致持续 OOM。因此，配置前应先回答三个问题：

• 保护的是确实不能被回收的工作集，还是只是希望服务“尽量快”？后者通常更接近 memory.low 的语义。
• 父 cgroup 下多个子树的 min 总需求，是否超过父级能提供的保护范围？
• 子树的 memory.current 是否长期低于 min？如果长期远低于，说明保护值可能偏大。

# 用键值方式保留单位，便于人工对照层级而不是机械相加
for file in memory.min memory.current memory.low memory.max; do
  if [ -r "$base/$file" ]; then
    printf '%-16s' "$file"
    cat "$base/$file"
  fi
done

# max 表示没有设置该项的有限上限；不要把它当成可用内存数值
printf '%s\n' '请结合父级保护和实际压力阅读以上值'

如果你需要的是“达到阈值后让服务降速、由外部程序观察并处理”，应优先研究 memory.high；如果需要的是不可回收的最小工作集，才考虑 memory.min。把二者混用，通常会把可调节的压力问题变成难排查的 OOM。

常见误区与一份阅读清单

实际落地时，可以按“挂载选项—层级关系—配置值—实际用量—压力现象”的顺序阅读。先确认递归语义，再判断父子边界，最后才调整数值；不要从一次 OOM 日志直接反推一个更大的 memory.min。

相关问题

memory.min 和 memory.low 有什么区别？

memory.min 是硬保护，在有效边界内不会被回收；memory.low 是尽力而为的保护，只有在没有未保护可回收内存时才优先保留。

memory.min 能不能限制服务最多使用多少内存？

不能。限制上限应看 memory.max；memory.min 解决的是回收保护，不是用量上限。

为什么子 cgroup 写入的数值没有完全兑现？

有效 min 受祖先边界限制；发生过度承诺时，子 cgroup 会按低于自身 min 的实际用量获得父级保护份额。