Linux 怎样读取 cgroup v2 内存压力事件

我排查 cgroup v2 内存问题时，最先看的通常不是一整段日志，而是目标目录下的 memory.events。它记录内存控制器已经发生过的事件：例如超过 memory.high 后被节流、逼近 memory.max，或者真的出现 OOM kill。这里的“压力事件”是累计计数，不等于 PSI 的实时压力百分比。

先读 memory.events 看事件类型，再用 memory.events.local 排除子 cgroup 的影响，最后把计数变化和 memory.current、memory.high、memory.max 放在一起判断。

• memory.events：默认按层级汇总当前 cgroup 及其子树的事件。
• memory.events.local：只看当前 cgroup 自身发生的事件。
• high 上升：超过高水位后进入直接回收和节流路径，不等于已经被杀。
• oom_kill 上升：才说明有进程被 OOM killer 终止。

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

我先把“内存压力事件”拆成两类

这次最容易误判的地方，是把 memory.events 和 PSI 的 memory 压力线索当成同一个东西。前者是内存控制器的事件计数器，适合回答“某种限制或 OOM 发生过几次”；它不是一个持续更新的压力比例，也不会直接告诉你任务在一段时间内被 stall 了多久。

因此，文章只围绕 cgroup v2 的 memory.events 字段展开。读到数字后，先记住它们是累计值：一次排查可以记下初始值，等待同一工作负载运行，再比较增量。

最小配方：按字段读取 memory.events

先把目标 cgroup 路径放进变量，再按键名打印文件内容。下面的写法不依赖字段固定顺序，因为内核文档明确要求按 key 查找，而不是按行号解释。

# 指向需要排查的 cgroup v2 目录，路径按实际服务层级替换
cg=/sys/fs/cgroup/my-service

# 先读取累计事件；每行都是“字段名 数值”
if [ -r "$cg/memory.events" ]; then
  while read -r key value; do
    printf '%-16s %s\n' "$key" "$value"
  done 

实际输出可能包含 low、high、max、oom、oom_kill，新内核还可能出现 oom_group_kill 等字段。不要写死“必须只有五行”；读取时保留未知 key，解析器也应按名称兼容新增字段。

我用两个文件确认“是谁触发了事件”

memory.events 的字段默认具有层级语义：当前 cgroup 的子树发生事件时，父级看到的计数也可能变化。这对观察一个服务树很有用，但如果你正在定位具体叶子 cgroup，就可能觉得数字“比本进程经历的多”。

这时用 memory.events.local 做对照。若 memory.events 上升而 memory.events.local 不变，优先检查子 cgroup；若两者一起上升，再回到当前 cgroup 的限制和任务分布。这个对照比单独盯着 oom 更容易找到归属。

把字段变化和 memory.high、memory.max 对上

读到 high 增长时，不要直接下结论说“服务快 OOM 了”。它表示任务超过高边界后被引导进行直接回收并可能被节流；如果工作负载长期稳定在高水位附近，high 增长本身可能是预期的限流信号。

max 表示使用量接近或试图超过硬上限；回收无法把使用量降下来时，才会进入 cgroup OOM 状态。oom 表示分配接近失败，oom_kill 则专门表示进程被 OOM killer 杀掉。复查时可以按下面的判断顺序记录：

1. 先读 memory.current，确认当前使用量是否接近限制。
2. 再看 memory.high 和 memory.max，区分节流边界与硬上限。
3. 比较 memory.events 与 memory.events.local 的增量，判断事件来自当前层还是子树。
4. 只有 oom_kill 增长时，才把“已有进程被杀”写进事故结论。

常见问题

为什么 high 增长但没有 oom_kill？

因为 high 主要表示高水位触发后的回收和节流；只要回收能把分配继续推进，就不必然进入 OOM kill。

memory.events 和 memory.events.local 应该选哪个？

看服务树整体用前者，定位当前 cgroup 自身用后者。排障时两个都读，比较增量通常更稳妥。

oom 增长是否等于进程已经被杀？

不等于。oom 是分配接近失败的事件计数，oom_kill 才对应被 OOM killer 终止的进程数。