Linux cgroup v2 memory.current 和 memory.max 怎么配合

在 Linux cgroup v2 中，这两个文件分工很明确：memory.current 负责回答“现在用了多少”，memory.max 负责回答“最多允许用多少”。前者是只读观测值，统计目标 cgroup 及其后代；后者是可写的硬上限，默认值为 max，表示不设置这一层的限制。实际部署时，先连续观察 memory.current，再给 memory.max 留出启动峰值和内核开销，最后用 memory.events 判断限制是否真的被触发。

先确认 cgroup 路径，再读取 memory.current

不要直接把系统根 cgroup 当成服务的统计口径。先从服务进程的 /proc/PID/cgroup 找到 cgroup v2 路径，再进入对应目录。下面的路径只是示例，生产环境应替换成实际服务路径：

# 把示例路径替换成服务进程所在的 cgroup 目录
CG=/sys/fs/cgroup/app.slice

# 确认父级是否把 memory 控制器分发给了子 cgroup
cat /sys/fs/cgroup/cgroup.subtree_control

# 读取当前用量与当前硬上限，两个文件的单位都是字节
cat "$CG/memory.current"
cat "$CG/memory.max"

如果父级的 cgroup.subtree_control 没有 memory，子层通常不会出现可用的 memory 控制接口。还要注意，memory.current 不是某一个进程的 RSS 快照，它会把该 cgroup 及后代的用量合并起来；因此服务拆成多个子 cgroup 后，读取父目录更适合看整个工作负载。

memory.max 是硬上限，不是推荐内存值

例如先把服务上限设为 1536 MiB：

# 1536 MiB 换算成字节后写入硬上限
printf '%s\n' $((1536 * 1024 * 1024)) > "$CG/memory.max"

# 需要取消这一层硬限制时，写入特殊值 max
printf '%s\n' max > "$CG/memory.max"

写入 memory.max 后，内核会尝试回收该 cgroup 的内存；如果仍无法降到限制以内，可能在该 cgroup 内进入 OOM。这个行为与“应用应该长期稳定使用的内存”不是一回事：上限过紧会把正常的启动峰值、缓存或并发请求变成故障。更稳妥的做法是先观察 memory.current 的峰值，再用 memory.max 做隔离边界；如果想先施加回收压力而不直接走 OOM，可另外设置更保守的 memory.high，但它不是硬上限。

用 memory.events 判断是节流、触顶还是 OOM

只读当前值只能说明“此刻有多少”，不能说明刚才是否发生过限额事件。对同一个 cgroup 再读事件文件：

# 读取层级事件；默认会包含后代 cgroup 的计数
cat "$CG/memory.events"

# 只关心当前 cgroup 自己发生的事件时，读取 local 版本
cat "$CG/memory.events.local"

high 增长表示进程曾因超过 memory.high 而被节流并进入直接回收；max 增长表示用量曾接近硬上限；oom 表示到达限制且分配即将失败；oom_kill 则表示确实有进程被 OOM killer 杀掉。默认的 memory.events 是层级统计，子 cgroup 的事件也可能让父级计数变化，所以要定位具体服务时优先同时记录父子路径和 memory.events.local。

常见问题

memory.current 超过 memory.max 是否一定马上杀进程？

不一定。内核会先尝试回收，某些情况下用量也可能暂时超过限制；持续无法满足分配时才可能进入 cgroup 内 OOM。

把 memory.max 设成 max 就没有内存限制了吗？

只代表这一层没有硬上限，父级 cgroup 的限制、主机可用内存和其他 memory 控制参数仍然可能影响服务。

为什么 memory.events 的 max 变大但 oom_kill 没变？

触及或接近硬上限不等于已经杀进程；回收成功、分配失败被调用方处理，或事件发生在后代但尚未形成 OOM，都可能出现这种组合。