systemd-oomd 与内核 OOM killer 有什么区别

我第一次排查“服务突然被杀”时，最容易混淆的是 systemd-oomd 和内核 OOM killer：两者都可能让进程最后表现为退出或收到 SIGKILL，但触发信号和证据位置完全不同。简单说，systemd-oomd 是用户态服务，会依据 cgroup v2 和 PSI（Pressure Stall Information）在内核真正耗尽内存前采取动作；内核 OOM killer 则是在内存回收仍无法满足分配请求时，进入内核的兜底路径。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd-oomd.service.html

这篇只比较触发信号、决策范围和可观测入口。我的建议是先建立证据链，再决定是否调整 unit 的内存边界；不要因为看到一次 status=9/KILL 就直接关闭 OOM 保护。

先看触发信号：压力阈值和分配失败不是一回事

systemd-oomd 的判断对象是被 systemd 观察的 cgroup。官方手册说明，它使用 cgroups-v2 和 PSI 监测系统或指定控制组；当 unit 配置了 ManagedOOMMemoryPressure=kill 或 ManagedOOMSwap=kill，并且条件达到限制时，oomd 会选择合适的后代 cgroup 并向其中的进程发送 SIGKILL。

内核 OOM killer 的入口更靠后：系统已经无法通过回收等方式满足内存分配，内核为了让系统继续运行而选择任务牺牲。它不是读取某个 systemd unit 的业务语义，也不会因为某个服务“看起来比较重要”就自动理解服务拓扑；选择会受到当前内存上下文和 oom_score_adj 等因素影响。

再看资源边界：oomd 为什么会选中一个控制组

我在测试环境里更愿意先检查 unit 的资源属性，而不是先改全局参数。下面是只读查看思路；命令中的 unit 名称需要替换成自己的服务，示例本身不代表已经在本机执行。

# 查看服务所在的 cgroup 和 systemd 资源属性，先确认观察边界
systemctl show my-worker.service \
  -p ControlGroup \
  -p ManagedOOMMemoryPressure \
  -p ManagedOOMSwap \
  -p MemoryAccounting

# 查看 systemd-oomd 当前监控到的控制组和压力信息
oomctl

# 读取服务最近的 systemd 日志，保留时间范围便于和内核日志对齐
journalctl -u systemd-oomd.service --since "30 min ago" --no-pager

如果 ManagedOOMMemoryPressure 和 ManagedOOMSwap 都没有配置为 kill，就不能只凭“机器内存很紧张”推断是 oomd 负责终止。即使配置了 kill，目标 unit 自己也不一定是候选对象；systemd-oomd 主要从符合条件的后代 cgroup 中选择，叶子 cgroup 或设置了 memory.oom.group=1 的组才更接近实际候选范围。

最后看证据链：把两个日志源放在同一条时间线上

排查时我会把 systemd 日志和内核日志分开取，再按时间排序。systemd-oomd 的日志能说明用户态服务是否观察到压力并采取动作；内核日志则用于判断是否真正进入了 OOM killer。两者都没有明确记录时，只看到应用的退出码还不够下结论。

# 只筛选 oomd 相关记录，避免把普通服务重启混在一起
journalctl -u systemd-oomd.service --since "1 hour ago" --no-pager

# 读取内核环形日志中的 OOM 线索；不同发行版日志前缀可能不同
dmesg --color=never | grep -Ei 'out of memory|oom-killer|killed process'

# 查看某个进程当前的 OOM 评分，辅助理解内核候选排序
cat /proc/1234/oom_score
cat /proc/1234/oom_score_adj

证据的组合可以这样读：只有 oomd 日志而没有内核 OOM 记录，更像是用户态按压力策略提前处理；只有内核 OOM 记录，则更像分配失败后的内核兜底；两边在相近时间都有记录，就要结合 cgroup、被杀对象和先后顺序，不能把后出现的日志当作唯一根因。

我的处理取舍：先修资源边界，再考虑全局策略

如果确认是 oomd，优先检查服务是否被放进了合适的 slice、是否开启了内存记账、压力阈值是否与业务延迟目标匹配，以及机器是否有可用 swap。官方文档也建议启用 swap 以便 oomd 更好工作。若确认是内核 OOM，则应继续看内存峰值、swap、容器或 cgroup 限制、oom_score_adj 与泄漏路径。

不建议把“关闭 systemd-oomd”当作默认修复，也不建议把 panic_on_oom 等内核策略直接改成生产常态。对我来说，最稳的顺序是：先保留日志证据，按服务划分资源边界，降低不必要的峰值，再用同一组时间线检查结果是否改变。

常见问题

systemd-oomd 和内核 OOM killer 会互相冲突吗？

它们不是同一个组件，但可能在同一台机器上先后工作。oomd 依据用户态配置提前终止控制组，内核 OOM killer 则在内核无法满足分配时介入；判断冲突前先按时间线拆开两次事件。

看到进程退出码 137 就能确定是内核 OOM 吗？

不能。137 通常表示进程被 9 号信号终止，但 systemd-oomd、内核 OOM killer 或其他管理动作都可能造成类似表现。至少要同时查看 unit 日志和内核日志。

应该优先看哪个命令？

如果 systemd-oomd 在运行，先看 oomctl 与 journalctl -u systemd-oomd.service；随后再对照内核日志。这样能先确认是否存在用户态监控路径，再判断是否有内核兜底记录。

把两者区别记成一句话就够了：systemd-oomd 更像按 cgroup 压力和 swap 信号提前做的用户态资源裁决，内核 OOM killer 是内存分配无法继续时的最后防线。先确认谁留下了什么证据，再调整资源边界，通常比盲目关闭保护更容易恢复系统稳定性。