Linux cgroup v2 memory.max 设置后进程为什么还能短暂超出

把 memory.max 写成 512M 后，memory.current 偶尔读到 513M、520M，并不等于 cgroup v2 失效。memory.max 是硬限制，但内核文档也明确说明，在特定情况下用量可能暂时超过它；只有回收无法把用量降下来、分配又无法继续满足时，才会在该 cgroup 内进入 OOM 处理。

短暂超出通常是并发计费与回收时机造成的窗口。先看 memory.events 是否出现 max、oom 或 oom_kill，再确认读取的是目标 cgroup 还是包含子树的统计，不能只凭一次 memory.current 快照下结论。

先别把 memory.max 当成瞬时读数

cgroup v2 的内存控制器会追踪匿名页、文件缓存，以及部分内核数据结构和 TCP socket 缓冲。memory.current 还包含后代 cgroup，所以父组的数值可能比业务进程看到的 RSS 大。多个线程或进程同时申请页面时，计费、回收和统计读取也不是一个不可分割的用户态操作。

memory.high 超过后会让任务承受重回收压力，极端情况下自身也可能越界，但它不会调用 OOM killer。memory.max 达到后则尝试回收；回收失败时才进入 cgroup OOM。管理员用非阻塞方式写入 memory.max 时，同步回收和 OOM 会推迟到目标任务下一次 charge request。

为什么短暂越界不一定是配置错误

“硬限制”约束的是内核记账和分配处理的结果，不是用户态轮询器每次读文件时都能看到的瞬时零超额曲线。并发 charge、页面回收尚未完成、缓存释放延迟，以及高阶分配等特殊路径，都可能让观测值短时间落在边界外。常规 0 阶分配通常会成功，除非 OOM killer 选择当前任务；某些分配则可能返回 -ENOMEM、重试或被静默忽略。

因此，看到一次 520M 不要立刻把上限改成 400M。先确认峰值持续时间和事件计数：若 max 增长而 oom_kill 不增长，说明碰到了边界但未必杀过进程；若 oom 和 oom_kill 同步增长，才应按真正的内存不足处理。生产环境还要把 swap 单独看，memory.swap.max 是 swap 资源的限制，不是 memory.max 的别名。

用 memory.events 判断到底有没有 OOM

先把变量指向实际目标 cgroup，再一次性读取限制、当前值、峰值和事件。示例只做观测，不会修改限制：

# 替换为服务实际所在的 cgroup 目录
CG=/sys/fs/cgroup/services/api

# 先看限制、当前用量和历史峰值
printf 'max='; cat "$CG/memory.max"
printf 'current='; cat "$CG/memory.current"
printf 'peak='; cat "$CG/memory.peak"

# local 只看当前 cgroup；events 默认可能包含后代事件
cat "$CG/memory.events.local"
cat "$CG/memory.stat"

重点看 memory.events.local 中的 max、oom、oom_kill。max 表示用量曾要越过边界；oom 表示达到限制且分配将失败；oom_kill 才表示有进程被 OOM killer 杀掉。memory.stat 再告诉你增长主要来自 anon、file、kernel 还是 sock，比盯着总数更容易找到方向。

按层级和进程归属复查配置

父 cgroup 的 memory.current 会汇总子树，而 memory.events 默认也是层级统计。若只关心本组，优先读 memory.events.local；同时检查进程到底加入了哪个目录：

# 用真实 PID 核对进程归属，避免看错 cgroup
PID=12345
cat "/proc/$PID/cgroup"

# 连续采样只是观察趋势，间隔不要小到压垮管理脚本
for i in 1 2 3; do
  date '+%H:%M:%S'
  cat "$CG/memory.current"
  cat "$CG/memory.events.local"
  sleep 1
done

还要检查写入限制的方式：普通写入会触发同步回收；用 O_NONBLOCK 调整限制时，回收和 OOM 可能延后。若业务确实需要提前释放，可使用 memory.reclaim，但它允许多回收或少回收，少于请求量时可能返回 -EAGAIN，不能把它当成精确的“清空内存”按钮。

常见问题

memory.current 超过 memory.max 就一定会杀进程吗？

不一定。短暂越界可能被回收收敛；只有回收无法满足分配且 OOM 处理被采用时，才会出现 oom，是否真的杀进程还要看 oom_kill。

为什么 memory.events 的 max 很大但业务没退出？

max 是触碰硬边界的计数，不等于 kill 次数，而且它可能汇总后代 cgroup。用 memory.events.local 和进程归属再定位。

应该把 memory.high 和 memory.max 设成同一个值吗？

通常不建议。memory.high 适合提前施加回收压力并留给管理程序处理，memory.max 用作最终硬边界；相同值会让业务更早持续节流，仍不能消除并发峰值。