Linux 服务为什么会被 OOM 杀掉：MemoryMax、日志证据与恢复边界

线上 Linux 服务突然退出，systemctl status 只留下一个“进程被杀”的结果时，先别急着把 MemoryMax 调大。要判断是不是 systemd 单元自己的 cgroup 触发了 OOM，至少要把单元配置、memory.events 计数和同一时间段的 journal 日志对上；如果是 systemd-oomd，还要看它记录的压力或 swap 原因。

先分清是硬限制还是整机内存压力

同样是服务退出，来源可能完全不同：单元的 cgroup 达到 MemoryMax，整机可用内存耗尽，或者 systemd-oomd 根据 memory pressure 主动选择了某个 cgroup。三者的处理顺序不一样。

判断时保留故障发生前后的时间窗口。计数器是累计值，单独读到一个非零数字，只能说明历史上发生过事件。

用 systemctl 和 cgroup 文件把证据串起来

先读取单元当前的资源配置和状态，再找到它对应的 control group。下面的命令只读配置和统计，不会重启服务：

unit=order-worker.service
systemctl show "$unit" \
  -p ControlGroup -p MemoryAccounting -p MemoryHigh -p MemoryMax \
  -p ManagedOOMMemoryPressure -p ActiveState -p SubState
systemctl status "$unit" --no-pager
systemctl show "$unit" -p ControlGroup --value

如果输出的 ControlGroup 是 /system.slice/order-worker.service，在 cgroup v2 挂载点下读取对应目录。生产环境不要把路径硬编码成另一台机器的层级，先用 findmnt -T /sys/fs/cgroup 确认挂载方式。

cg=/sys/fs/cgroup/system.slice/order-worker.service
printf '%s\n' '--- limits ---'
cat "$cg/memory.current" "$cg/memory.peak" "$cg/memory.high" "$cg/memory.max"
printf '%s\n' '--- events ---'
cat "$cg/memory.events"
printf '%s\n' '--- local events ---'
cat "$cg/memory.events.local"

最有价值的组合通常是：memory.peak 接近或达到 memory.max，同时 memory.events 的 max、oom 或 oom_kill 在故障后增加。若只看到 high 增加，说明服务经历了高水位回收，不足以证明已经被 OOM 杀掉。

把 journalctl 时间线和 OOM 来源对上

接着查单元日志与内核日志。不要只搜索“killed”，因为不同发行版和 systemd 版本的表述可能不同：

unit=order-worker.service
systemctl show "$unit" -p ExecMainCode -p ExecMainStatus -p Result
journalctl -u "$unit" --since "10 min ago" --no-pager
journalctl -k --since "10 min ago" --no-pager \
  | rg -i 'out of memory|oom-kill|killed process|memory cgroup'
journalctl -u systemd-oomd --since "10 min ago" --no-pager

如果内核日志指出某个 memory cgroup 内的进程被杀，并且单元的事件计数同步增长，可以把根因收敛到该 cgroup。若只有 systemd-oomd 日志，看到 memory-pressure 或 memory-used，则要继续检查 oomd 管理的层级，不要把它写成内核直接触发的 MemoryMax。

先观察 MemoryHigh，再决定是否改 MemoryMax

MemoryHigh 更适合作为观察和降压边界：超过它会让进程承受更强的回收压力，但本身不会触发 OOM killer。硬上限 MemoryMax 则是最后一道边界，设置过低会把正常的缓存峰值变成服务退出。

# 先建立可回滚的 drop-in，不直接改发行版原文件
sudo systemctl edit order-worker.service

[Service]
MemoryAccounting=yes
MemoryHigh=768M
MemoryMax=1G

保存后执行：

sudo systemctl daemon-reload
sudo systemctl restart order-worker.service
systemctl show order-worker.service -p MemoryHigh -p MemoryMax -p ControlGroup
systemctl is-active order-worker.service

这次重启本身会改变业务状态，所以应安排在可接受窗口。验收不能只看 active：至少观察一段真实负载，记录 memory.current、memory.peak 和 memory.events 的变化，并确认请求或任务队列没有持续堆积。

四个容易误判的恢复边界

单元的 MemoryMax 不等于整机总内存

它限制的是单元及其子孙 cgroup 的记账范围。提高它之前，要确认上层 slice、容器或宿主机还有可用余量，否则只是把问题从服务边界推到更大的范围。

累计事件不能代替故障时间线

memory.events 是计数器。修复前后各保存一次，并把读取时间写进值班记录，才能判断本次重启是否又产生了新的 oom_kill。

只重启服务可能掩盖泄漏

重启能清空进程内存，却不会解决持续增长的缓存、批量读取或未释放资源。用 memory.peak 和应用自己的指标观察增长速度，必要时再回到堆、缓存和请求并发排查。

回滚要回到 drop-in 文件

如果新限制导致启动失败或延迟明显升高，删除对应的 /etc/systemd/system/order-worker.service.d/ drop-in，执行 daemon-reload 后再按原配置启动。不要只在命令行临时改值，临时值很容易让下一次重启恢复成另一套配置。

相关问题

MemoryHigh 超限会直接杀进程吗？

不会。它主要触发更强的回收和限流；如果随后仍触碰硬边界或整机发生 OOM，才可能出现进程被杀。

为什么 memory.events 的 oom_kill 没增长但服务退出了？

可能是服务自身退出、被管理员停止、依赖失败，或 systemd-oomd 在另一个层级做了处理。应同时看 Result、内核日志和 oomd 日志，不能只凭服务退出状态下结论。

调大 MemoryMax 前最少看哪些指标？

至少看 memory.peak、memory.current、memory.events，再结合请求并发、缓存大小和宿主机余量。没有峰值和时间线，调参只是把故障推迟。

总结

Linux 服务的 OOM 排查要先建立证据链：单元配置确定边界，cgroup 文件确认峰值和事件，journalctl 区分内核 OOM 与 systemd-oomd，最后用可回滚的 drop-in 做小步调整。把 MemoryHigh 当观察线、把 MemoryMax 当硬边界，恢复后继续看峰值和事件计数，才不会把一次重启误当成问题解决。