Linux cgroups v2 怎么判断容器内存限制是否生效

容器里执行 free -h 看到的往往是宿主机视角，不能单独证明容器的内存上限。cgroups v2 的判断应落到当前 cgroup 的控制文件：memory.max 看硬限制，memory.current 看当前用量，再用 memory.events 判断是否触顶。三者读到的层级一致，才能说明限制确实作用在这个容器上。

先区分 cgroups v2 的限制值和当前用量

cgroups v2 把控制器统一挂在 cgroup2 文件系统下。先在容器内确认接口存在，再读取当前进程的相对路径。下面的命令只读文件，不依赖 Docker CLI，适合排查 Docker、containerd 或 Kubernetes 容器。

# cgroup.controllers 存在且能读到内容，通常说明这里挂载的是 cgroups v2
test -r /sys/fs/cgroup/cgroup.controllers && cat /sys/fs/cgroup/cgroup.controllers

# 记录当前进程在 v2 层级中的相对路径；统一层级的格式是 0::/...
awk -F: '$1 == "0" {print $3}' /proc/self/cgroup

不要把 v1 的 memory.limit_in_bytes 当成 v2 文件。v2 的内存接口以 memory. 开头，文件通常就在当前路径对应的目录中。相对路径为空时，进程可能位于根 cgroup；容器场景下更常见的是某个由运行时创建的子目录。

从容器内确认 memory.max 是否真正落到当前 cgroup

假设上一步得到的相对路径是 /kubepods.slice/workload.slice/demo.scope，就把它拼到 /sys/fs/cgroup 后读取。不要硬编码宿主机上的 Docker 长 ID，因为不同运行时和 systemd 驱动会使用不同目录名。

# 读取当前进程对应的 v2 路径，去掉开头的斜杠后拼接挂载点
REL=$(awk -F: '$1 == "0" {print $3}' /proc/self/cgroup)
CG=/sys/fs/cgroup${REL}

# memory.max 为 max 表示没有硬限制；数字单位是字节
printf 'cgroup=%s\n' "$CG"
cat "$CG/memory.max"

# memory.current 是当前 cgroup 及其后代的用量，单位同样是字节
cat "$CG/memory.current"

如果 memory.max 是 max，限制并没有在这个层级生效，不能因为容器内的进程数量少就推断它有内存上限。如果读到数字，再把它和 memory.current 放在一起解释：例如上限是 536870912，约等于 512 MiB；当前值低于它，只能说明此刻尚未触顶。

用 memory.current 和 memory.events 做一次回归检查

内存限制是否“生效”，不能只看一次 memory.current。应用可能已经释放内存，也可能只在高峰时短暂触顶。v2 的 memory.events 会记录当前 cgroup 及后代相关的内存事件，可用来补足这个时间维度。

# 读取事件计数，重点关注 max、oom 和 oom_kill 是否大于 0
while read -r key value; do
  printf '%-10s %s\n' "$key" "$value"
done 

max 增加，说明 cgroup 发生过达到 memory.max 的分配压力；oom 或 oom_kill 增加，则说明已经进入 OOM 处理路径。事件计数是累计值，重启容器或重建 cgroup 后会变化，所以排障记录应同时写下采集时间和 cgroup 路径。

常见问题

容器里的 free -h 为什么和 memory.current 不一致？

free 主要反映内核提供给该命名空间的内存视图，不能代替 cgroup 控制文件。限制排查应以当前 cgroup 的 memory.max 和 memory.current 为准。

memory.max 有数字但 current 一直很小，是否说明限制没生效？

不是。它通常表示当前用量还没有接近上限。要确认运行期间是否触顶，记录压测前后的 memory.events，并检查是否读取了当前进程所属的 cgroup。

为什么在容器里找不到 memory.max？

常见原因是宿主机仍使用 cgroups v1、memory 控制器没有挂到当前层级，或容器被放在 cgroups v2 根层级之外的不同路径。先确认 cgroup.controllers，再根据 /proc/self/cgroup 组装路径。