接口是什么
memory.oom.group 决定该 cgroup 发生内存不足时如何处理成员进程：设为 1 表示组内进程作为整体一起被终止，默认值 0 只终止触发 OOM 的那个任务。容器场景通常需要整组终止——只杀一个进程往往留下半死不活的依赖进程，形成不一致状态，或让控制器反复重启单组件而不是干净重启。
基本信息
| 接口路径 | /sys/fs/cgroup/<组>/memory.oom.group |
|---|---|
| 取值 | 0（默认，只杀触发的那个任务）/ 1（整组终止） |
| systemd 对应 | MemoryOOMGroup=1（较新版本提供） |
| 配套接口 | memory.max（边界）、memory.events（oom 与 oom_kill 计数） |
| 触发前提 | 需要有明确的限额边界，否则组级 OOM 很少发生 |
| 适用范围 | 容器、生命周期一致的成组进程 |
典型使用场景
- 容器或 Pod：OOM 时整组退出，交给编排系统干净地重建
- 多进程服务（主控 + worker）：避免只杀掉 worker 留下主控空转
- 批处理作业：整组终止以避免残留进程继续占用资源
- 验证重启行为：确认 OOM 后是整组消失而不是留下孤儿进程
- 与监控联动：用 memory.events 的 oom_kill 增长触发告警与复盘
查看与设置
查看与设置
cat /sys/fs/cgroup/myapp.slice/memory.oom.group # 当前设置
cat /sys/fs/cgroup/myapp.slice/memory.events # 其中的 oom 与 oom_kill 计数
echo 1 | sudo tee /sys/fs/cgroup/myapp.slice/memory.oom.group # 开启整组终止
systemctl set-property myapp.service MemoryOOMGroup=1 # systemd 侧设置（版本较新）
dmesg -T | grep -i -m5 oom # 从内核日志确认终止了哪些进程
journalctl -k -g oom --since '-1h' # 回溯近一小时内的 OOM 事件取值对照
| 取值 | 终止范围 | 适用场景 |
|---|---|---|
| 0 | 仅触发 OOM 的单个任务 | 组内进程相互独立、希望尽量保留服务的场景 |
| 1 | 该 cgroup 内的全部进程 | 容器与生命周期一致的多进程服务 |
整组终止会把同组内健康的进程一并带走。把不相关的服务混在同一个 cgroup 里时这个行为尤其危险，组划分应尽量与服务的生命周期一致。
反过来，如果容器场景不开启该选项，容易出现「只有一个 worker 被杀、其他进程卡在不可用状态」的中间状态，表现为服务半死而非重启，排查时容易被误判为应用 bug。