Linux cgroup v2 memory.max 如何判断进程被限制

排查 Linux 进程是否被 cgroup v2 限制，不能只看宿主机剩余内存，也不能只看一次 memory.current。正确做法是先从进程的 /proc/PID/cgroup 找到目标目录，再读取同一目录下的 memory.max、memory.current 和 memory.events：memory.max 是硬上限，memory.current 说明当前用量，memory.events 中的 max、oom、oom_kill 才能说明限制是否真的被触发。

官方地址：https://docs.kernel.org/admin-guide/cgroup-v2.html

先沿进程路径找到真正的 cgroup

同一台机器上可能有多个 cgroup，先确认 PID 所属路径，否则读到别的服务目录会得到完全错误的判断。cgroup v2 的进程行通常形如 0::/system.slice/example.service，第二个冒号后的内容就是统一层级中的相对路径。

# 把 1234 替换为待排查进程的 PID
pid=1234
# 读取进程在 cgroup v2 中的相对路径
cg_rel=$(awk -F: '$1 == "0" {print $3}' "/proc/$pid/cgroup")
# 常见挂载点是 /sys/fs/cgroup；先确认它确实是 cgroup2
mountpoint=/sys/fs/cgroup
findmnt -T "$mountpoint" -o FSTYPE,TARGET
# 拼出该进程对应的 cgroup 目录
cg_dir="$mountpoint$cg_rel"
printf 'cgroup=%s\n' "$cg_dir"

如果 findmnt 显示的不是 cgroup2，或者 /proc/$pid/cgroup 没有 0:: 行，先处理挂载或版本问题，不要直接套用下面的判断式。

读取 memory.max 和 memory.current，先判断“有没有限制”

在目标目录中读取两个文件。内核文档规定，memory.max 是该 cgroup 的内存使用硬限制，默认值为 max；memory.current 统计当前 cgroup 及其后代的用量，单位是字节。

# 读取硬上限和当前用量；不要把宿主机 free 输出当成 cgroup 用量
limit=$(cat "$cg_dir/memory.max")
current=$(cat "$cg_dir/memory.current")
printf 'memory.max=%s\nmemory.current=%s bytes\n' "$limit" "$current"

# 只有数字上限才计算占用比例；max 表示没有配置硬上限
if [ "$limit" != "max" ]; then
  awk -v cur="$current" -v max="$limit" \
    'BEGIN { printf "usage=%.1f%%\n", cur * 100 / max }'
else
  echo 'usage=unlimited-by-memory.max'
fi

这里有一个容易误判的地方：子 cgroup 的 memory.max 不是整棵树唯一的限制。祖先 cgroup 也可能有更小的上限；而且 memory.current 包含后代进程，所以排查服务时要把同一目录下的子 cgroup 一起考虑。

用事件计数确认是否真的触顶

把当前配置和实际事件分开看。memory.events 是按键值记录的文件，默认包含当前 cgroup 及后代的层级统计；其中 max 表示用量曾经接近或越过 max 边界，oom 表示达到限制并出现分配失败风险，oom_kill 表示属于该 cgroup 的进程被 OOM killer 杀死。

# 显示层级事件；同一服务有子 cgroup 时，这里可能包含后代计数
cat "$cg_dir/memory.events"

# 只关心几个判断键，缺少某个键时保留 0 便于脚本化读取
for key in max oom oom_kill; do
  value=$(awk -v k="$key" '$1 == k {print $2}' "$cg_dir/memory.events")
  printf '%s=%s\n' "$key" "${value:-0}"
done

# 需要区分本目录事件与后代事件时，再读取 local 文件
cat "$cg_dir/memory.events.local"

实战上可以这样下结论：只有数字 memory.max，结论是“配置了限制”；数字上限加上 current 接近它，结论是“正在逼近限制”；如果 max 从基线开始增长，说明确实碰到过边界；再看到 oom 或 oom_kill 增长，才有充分依据把异常与 cgroup 内存限制联系起来。先记一次基线，过一段时间再比较计数，比只贴一份快照更可靠。

四个常见误区和一份排查清单

• 把 max 当成“已经超限”。 它是事件计数，不是布尔值；先比较前后两次读取。
• 只看 memory.current。 当前值低于上限时，之前发生过的 OOM 仍可能留在事件计数里。
• 忽略层级统计。 memory.events 默认可能包含后代，想确认当前目录本身就看 memory.events.local。
• 只看进程，不看同组服务。 cgroup 的限制对象是层级资源域，服务管理器或容器运行时可能把多个进程放在同一目录。

最终检查顺序可以固定为：确认 PID → 读取 0:: 路径 → 确认 cgroup2 挂载点 → 读取 memory.max 与 memory.current → 记录并比较 memory.events → 必要时对照 memory.events.local。这样得到的是“配置、当前状态、历史事件”三层证据，而不是凭一条命令猜原因。

相关问题

memory.max 是 max，进程还会因为内存被杀吗？

会。它只表示这个 cgroup 没有设置硬上限，宿主机内存压力、祖先 cgroup 限制或其他资源约束仍可能导致失败；继续沿祖先层级和系统日志排查。

memory.current 没到 memory.max，为什么仍然出现 OOM？

一次读取只是瞬时值，分配可能在采样间隔内触顶；另外要检查祖先 cgroup、后代统计和 memory.events 的累计值。

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

想知道整个服务树是否发生过事件看 memory.events；只想确认当前 cgroup 自己产生的事件看 memory.events.local。