Linux cgroups v2 怎么限制服务内存并读取 OOM 结果

服务的 RSS 从 420MB 慢慢涨到 900MB，最容易犯的错是直接把它“杀掉”。在 cgroups v2 中，更稳妥的做法是给 systemd 服务配置两条线：MemoryHigh=700M 让内核在超线后施加回收压力，MemoryMax=1G 作为最终硬上限；再到该服务的 cgroup 目录读取 memory.current 和 memory.events，判断是接近上限、进入 OOM，还是子 cgroup 的事件被累计上来了。

先把服务和 cgroup v2 对上

先不要凭服务名猜目录。确认统一层级，再让 systemd 告诉我们实际的 ControlGroup 路径：

# 确认当前文件系统类型应为 cgroup2fs
stat -fc '%T' /sys/fs/cgroup

# 查看服务被放进哪个 cgroup；变量替换成实际 unit 名称
SERVICE=worker.service
CGROUP_PATH=$(systemctl show "$SERVICE" -p ControlGroup --value)
CGROUP_DIR="/sys/fs/cgroup${CGROUP_PATH}"
printf 'cgroup=%s\n' "$CGROUP_DIR"

# 先建立基线：当前用量、硬上限和事件计数
cat "$CGROUP_DIR/memory.current"
cat "$CGROUP_DIR/memory.max"
cat "$CGROUP_DIR/memory.events.local"

如果第一条不是 cgroup2fs，就别急着写 v2 文件；主机可能仍由旧的 v1 层级接管。ControlGroup 返回的路径才是本次服务的观测入口，后续所有计数都应在同一目录读取。

用两条内存线控制服务，而不是只设一个数字

为服务创建 drop-in：

# 打开 worker.service 的持久化资源配置片段
sudo systemctl edit worker.service

# 在 [Service] 段写入：先限流，后硬止损
[Service]
MemoryHigh=700M
MemoryMax=1G

# 让 systemd 重新读取 unit，并重启使配置进入服务生命周期
sudo systemctl daemon-reload
sudo systemctl restart worker.service

MemoryHigh 适合放在可接受性能下降的位置：超过后进程会遭遇直接回收和节流，但它本身不会调用 OOM killer。MemoryMax 才是硬上限，内核尝试回收仍无法满足新分配时，会在这个 cgroup 内进入 OOM 处理。两个值不要贴着服务的正常峰值设置，至少给运行时、页缓存和短时并发留出余量。

配置后检查 systemd 看到的值，而不是只检查编辑器是否保存：

# 检查 unit 的最终属性，确认 drop-in 已合并
systemctl show worker.service -p MemoryHigh -p MemoryMax

# 若只想临时压测，可运行时设置；持久化配置仍应写入 drop-in
sudo systemctl set-property --runtime worker.service MemoryHigh=700M MemoryMax=1G

从 memory.events 读出 OOM 到底发生了什么

把采样前后的计数保存下来，比看一次瞬时值可靠：

# 读取层级累计值与本 cgroup 本地值，避免把后代事件混在一起
for file in memory.current memory.max memory.events memory.events.local; do
  printf '\n[%s]\n' "$file"
  cat "$CGROUP_DIR/$file"
done

# 只抽取判断 OOM 最关键的计数
awk '$1 ~ /^(max|oom|oom_kill|oom_group_kill)$/ {print}' \
  "$CGROUP_DIR/memory.events.local"

max 增加，说明用量曾逼近硬上限；oom 增加，说明分配已到达限制并即将失败；oom_kill 增加，才表示有进程被 OOM killer 杀掉。若 memory.events 的数字变了而 memory.events.local 没变，优先检查子 cgroup：前者默认是层级统计，后者才只看当前组。

若服务由多个协同进程组成，可以在确认“部分进程存活”会破坏任务完整性后再考虑：

# 让当前 cgroup 作为一个不可分割工作负载参与 OOM 处理
echo 1 | sudo tee "$CGROUP_DIR/memory.oom.group"

# 记录配置后的本地事件基线，便于下次故障比较增量
date -Is
cat "$CGROUP_DIR/memory.events.local"

Delegate=yes 只解决子层级管理，不会突破父级限制

只有服务本身需要创建和管理子 cgroup 时才启用委派，例如运行时要把不同 worker 分到自己的资源组：

# 仅在服务确实需要管理子 cgroup 时开启委派
sudo systemctl edit worker.service

[Service]
Delegate=yes

# 委派配置改变后重新加载并重启服务
sudo systemctl daemon-reload
sudo systemctl restart worker.service

委派给服务的只是它所在目录下的组织和控制空间。子 cgroup 的内存限制仍受父级 MemoryMax 和更上层 slice 约束，不能把资源“搬出”服务边界。若服务不需要创建子层级，不要为了“看起来更完整”打开 Delegate。

常见问题

MemoryHigh 超过后一定会重启服务吗？

不会。它主要施加回收压力和节流；要控制最终上限，应同时设置合理的 MemoryMax，并由服务自身或外部监控处理持续压力。

为什么 memory.events 比 memory.events.local 大？

前者默认包含后代 cgroup 的层级累计事件，后者只记录当前 cgroup 本地事件。服务启用了子 worker 组时，这个差异尤其常见。

设置 MemoryMax 后还能让子进程继续运行吗？

可以，正常子进程仍在服务 cgroup 或其后代中运行；但后代共同受父级资源边界约束，不能用 Delegate=yes 绕过上限。

回滚时删除 drop-in 中的内存设置，再执行 daemon-reload 并重启服务。生产排查应保留变更前后的 memory.current、memory.events.local 和服务日志，这样才能把“内存涨了”还原成压力、硬上限还是实际 OOM kill。