Linux cgroup v2 memory.events 怎么看：区分回收、限额与 OOM 的证据链

服务没直接挂掉，但接口延迟开始飘红，监控面板里的 cgroup 内存曲线眼看就要顶到上限。遇到这种场景，单看 memory.current 只能拿到当前的内存使用数值，根本分不清是后台页回收带来的性能波动、撞到了预先设的硬限额，还是已经悄悄触发了OOM杀进程。靠谱的排查思路是把几个配套指标串起来读：先确认实时内存占用，再核对历史事件计数和配置的硬上限，最后把父层级的汇总数据和当前cgroup的本地统计做交叉校验。

排查 cgroup v2 内存相关问题时，优先读取 memory.current、memory.events、memory.events.local 和 memory.max；出现 high 不等于 OOM，出现 max 才说明硬上限曾被触碰，oom 与 oom_kill 则用于确认 OOM 路径。

先把四个文件的职责分开

假设目标 cgroup 是 /sys/fs/cgroup/demo-worker。先别急着改配置参数，按下面的顺序读取原始值即可：

cg=/sys/fs/cgroup/demo-worker
printf '%s\\n' '--- current ---'; cat "$cg/memory.current"
printf '%s\\n' '--- events ---'; cat "$cg/memory.events"
printf '%s\\n' '--- local events ---'; cat "$cg/memory.events.local"
printf '%s\\n' '--- max ---'; cat "$cg/memory.max"
printf '%s\\n' '--- high ---'; cat "$cg/memory.high"

这些文件记录的不是同一类指标。memory.current 是实时统计的字节数；memory.max 和 memory.high 是预设的边界值，也可能是 max 特殊标记；事件类文件则是按固定字段累加的计数。可以先参考下面这张表，避免把实时状态和历史事件混为一谈。

用 events 读数判断到底发生了什么

事件文件是关联现象和根因的核心。high 数值上涨，说明内存使用已经进入高水位压力路径，内核可能会限制任务的内存分配速度；这个现象完全不等于内核已经开始杀进程。max 数值上涨，说明内存使用量曾经触碰到 memory.max 的硬边界。只有观测到 oom 或 oom_kill 数值上涨，才有足够证据确认流程已经走到了OOM处理分支。

awk '$1 ~ /^(low|high|max|oom|oom_kill)$/ {print}' "$cg/memory.events"
awk '$1 ~ /^(low|high|max|oom|oom_kill)$/ {print}' "$cg/memory.events.local"
printf 'current=%s\\n' "$(cat "$cg/memory.current")"
printf 'high=%s\\n' "$(cat "$cg/memory.high")"
printf 'max=%s\\n' "$(cat "$cg/memory.max")"

如果父 cgroup 的 memory.events 有计数增长，而 memory.events.local 没有对应变化，优先往下排查子 cgroup；父层的层级统计会把子树所有的事件自动汇总进来。反过来，两个位置的同名字段同时增长，才能判定是当前 cgroup 自己直接触发了该事件。

三个常见读数组合

• high 增加、max 为 0、oom 为 0：先排查后台回收和分配限速带来的性能影响，不要直接把问题归因到OOM。
• max 增加、oom 为 0：硬上限确实被触碰过，但未必已经触发OOM杀进程，继续核对任务延迟和接口重试日志。
• oom 或 oom_kill 增加：结合cgroup运行日志、进程退出时间点和内核dmesg日志交叉复盘OOM事件，不能只凭监控曲线就下结论。

把 memory.high 放在硬上限之前

memory.high 更适合作为压力告警信号和预调节阈值，memory.max 是内存限制的最后一道硬边界。生产环境可以让工作负载先在 memory.high 附近提前暴露出回收或分配变慢的问题，再结合队列长度、请求延迟和事件计数决定是否扩容或调整上限；不要看到一次瞬时流量峰值就直接把 memory.max 调得非常大。

# 只读确认当前边界
cat "$cg/memory.high" "$cg/memory.max"

# 修改前记录基线；示例数值应按机器内存和业务峰值评估
date -Is
cat "$cg/memory.current" "$cg/memory.events" "$cg/memory.events.local"

# 由具备权限的运维流程执行变更，变更后立即复查
# printf '%s\\n' 2147483648 > "$cg/memory.high"
# cat "$cg/memory.high" "$cg/memory.events"

调整边界参数时要先记下可回滚的基准值，同时确认父 cgroup 剩余的可用内存配额。给子 cgroup 写入高于父级可支配范围的配置值，完全替代不了整体集群的容量规划；直接把 memory.max 无脑放大，反而可能把内存回收的压力转移给整个宿主机的全局调度。

发布前用一轮只读检查收口

问题修复或者完成扩容之后，至少连续采样两次数据做校验，不要只截一张显示服务正常的监控图就收尾。下面的检查项可以直接加到值班排查手册里，核心是确认事件计数不再持续增长、当前内存用量距离配置边界还有足够余量，以及业务进程确实运行在目标cgroup路径下。

for i in 1 2; do
  date -Is
  printf 'current '; cat "$cg/memory.current"
  cat "$cg/memory.events" | egrep '^(high|max|oom|oom_kill) '
  sleep 10
done

cat "$cg/cgroup.procs" | head
systemctl show demo-worker.service -p ControlGroup -p MemoryCurrent -p MemoryHigh -p MemoryMax

如果 high 持续增长但 max 和 OOM 计数都没变化，说明问题更偏向高水位压力或者常驻内存集的后台回收；如果 max 继续上涨，就要回到请求峰值、并发度配置和缓存策略维度核对原因；如果 oom_kill 增长，就要把进程退出和服务恢复的动作完整纳入事故时间线排查。

常见问题

memory.events 和 memory.events.local 应该看哪一个？

先搞清楚两者的差异。前者统计值包含所有子 cgroup 的汇总数据，后者只记录当前 cgroup 自身的事件，本地统计值更适合定位真正的触发点。

memory.current 接近 memory.max 就是 OOM 吗？

不是。它只说明当前内存用量快要触碰到硬边界；有没有真的走过OOM处理流程，要结合 oom、oom_kill 计数和系统日志综合判断。

high 增加后要马上调大 memory.max 吗？

不一定。先确认请求延迟、内存回收速率、并发量级和工作集的变化情况；只有确认容量确实不足且宿主机还有剩余资源时，才按照基准线逐步调整边界参数。

为什么 memory.max 显示 max 还会有内存压力？

max 表示该 cgroup 自身没有设置硬上限，不代表宿主机拥有无限内存，业务运行仍然可能受到全局内存回收、父cgroup配额或者其他系统资源的约束。

总结

Linux cgroup v2 的内存排查要把「实时状态值」和「历史事件计数」分开看：memory.current 告诉你当前进程实际用了多少内存，两个events文件能回溯到哪一类边界曾经被触碰，memory.high 与 memory.max 则说明压力先后触发了哪两道阈值。按这个顺序采样数据、调整配置、复查验证，就能把一条模糊的内存告警线索，还原成完全可复现、可核对的完整根因证据链。