Linux 服务器进程被 OOM Killed 怎么排查：从内核日志到 cgroup 内存上限的完整流程

凌晨的订单服务突然少了一个实例，应用日志只留下一行 Killed，重启后又能短暂恢复。遇到这种情况，先别急着把锅甩给 Go、Java 或数据库连接池：Linux 大概率已经触发了 OOM 终止机制，或是容器的 cgroup 内存上限先被击穿了。把“谁杀的进程、触发原因、内存峰值位置”这三件事查清楚，后续修复才不会变成盲目往上堆内存的无效操作。

先把“应用异常退出”与 Linux OOM 机制区分开

应用自身崩溃时，业务日志往往只能记录到进程突然消失的节点，真正的调度决策过程全部存在内核日志里。下面以 systemd 管理的 orders-api.service 为例，先找到最近一次受害进程和完整的触发上下文：

sudo journalctl -k --since "30 min ago" | rg -i 'out of memory|killed process|oom'
sudo journalctl -u orders-api.service --since "30 min ago"

如果输出里有 Out of memory: Killed process 18472 (orders-api)，并且后续systemd的日志里明确记录了服务被重启，基本可以排除是应用主动退出的情况。日志相邻位置一般还能看到匿名页、文件页、swap占用和进程评分等参考信息，建议把整段上下文全部留存，不要只截取“Killed process”这一行就当证据。

排查顺序：从内核证据逐层追溯到内存峰值

一台8GB内存的虚拟机上的服务被杀，不代表机器直接要扩容到16GB。完整排查建议顺着下面这条链路走，每一步都能拿到更精准的结论指向。

主机内存压力优先看长期趋势，别只取故障后一瞬间的快照

刚发生故障的时候跑一次 free -h 能拿到当前状态，但它没法还原五分钟前出现过的瞬时尖峰。如果监控里RSS占用呈锯齿状波动，并且在某个导入任务启动后突然陡升，问题一般出在单次大对象积累、缓存未释放或是并发数过高；如果多台同配置机器的内存占用都在缓慢爬升，就要把排查范围扩大到全链路流量、最近上线的部署版本和共享依赖组件上。

ps -eo pid,ppid,comm,rss,%mem --sort=-rss | head -15
vmstat 1 5
sudo systemctl status orders-api.service --no-pager

这里有个很容易踩的误判点：Linux会自动把可回收的文件缓存拿来加速读写操作，因此全局统计里的“used”数值很高，并不直接等于内存已经耗尽。更有参考价值的判定指标是 available、持续的swap换入换出动作，以及应用RSS占用和资源限额之间的剩余空间。

容器和 systemd 托管的服务要单独检查 cgroup 上限

主机看起来还有3GB可用内存，容器仍然可能因为配置了512MiB的上限被直接杀掉。cgroup v2环境下，先进入对应服务或者容器的资源目录，再读取三个核心指标文件：

# 容器或服务的 cgroup 路径因运行环境而不同，先确认实际目录
cat /sys/fs/cgroup//memory.current
cat /sys/fs/cgroup//memory.max
cat /sys/fs/cgroup//memory.events

memory.current 是当前的实际内存使用量，memory.max 是配置的内存硬上限；当上限显示 max 时代表没有设置固定的内存限额。memory.events 里的 oom 与 oom_kill 计数指标非常关键：这两个数值增长的时候，哪怕主机剩余内存还很充足，也说明当前cgroup已经成为了触发OOM的边界。

两类不同的OOM现象对应完全不同的处理方向

• 主机级OOM：多进程RSS同时上涨、可用内存长期处于低位、swap读写活跃。优先排查流量放大、批处理任务并发、缓存占用和宿主机本身的容量是否匹配。
• cgroup级OOM：主机全局内存尚有余量，但 memory.events 的 oom_kill 计数持续增长。优先核查容器或者服务的资源限额、应用堆内存配置，以及当前cgroup下挂载的其他辅助进程占用。

动手修复前先给内存峰值画出明确的合理边界

确认是哪一层边界触发了OOM之后，不建议直接把 memory.max 配置直接翻倍。先把日常请求量、单个任务内存占用、并发数和临时缓存大小整理成一个简单的内存预算。举个例子，一个数据导入任务的峰值占用约70MiB，同时允许6个任务并行执行，应用基础RSS占用260MiB，再预留30%的安全余量，512MiB的容器配置显然没有多余的缓冲空间。

基础 RSS 260MiB
单任务峰值 70MiB × 并发 6 = 420MiB
合计约 680MiB，尚未包含运行时波动和日志缓冲

这种场景下更可控的改动，往往是把数据导入改成分批读取、限制同类任务的最大并发数，或是把大对象缓存改成带容量上限的LRU淘汰机制。只有当内存预算和实际业务场景确实需要更大的工作集空间时，再去提高cgroup的资源限额，同时要为宿主机预留出系统进程和其他服务运行的必要空间。

上线后的复查要同步核对四个维度的信号

修复代码提交之后，用一段接近真实流量分布的压测或者预发环境流量回放来观察相关指标。别只看接口没有报错就结束，OOM类问题往往要持续运行十几分钟之后才会露出明确的异常迹象。

1. 服务RSS占用是否在任务执行完成后正常回落，而不是每轮任务跑完都把内存基线抬高。
2. memory.current 数值是否始终和 memory.max 保留足够的安全距离。
3. memory.events 的 oom、oom_kill 计数是否不再持续上涨。
4. systemctl status 的重启次数保持稳定，内核日志里没有生成新的OOM相关记录。

如果单纯把限额提高之后服务不再退出，但RSS占用仍然在持续上涨，问题其实只是被更大的容器容量藏住了。这时候还要回到对象生命周期管理、缓存淘汰策略和并发队列配置上继续排查，不要直接把升级机器规格当成最终解决方案。

常见问题

日志里只输出Killed字样，一定就是OOM机制触发的吗？

不一定。外部发送终止信号、人工操作关停或是编排系统主动回收也可能产生类似的日志表现。要以同一时间段的内核日志和服务事件记录作为判定依据，拿到明确的OOM相关记录才能下最终结论。

机器配置了swap分区就不会触发OOM了吗？

不是。swap只能缓冲一部分短时内存压力，cgroup层的硬上限仍然可能先被触发；而且频繁的内存换页动作会让服务接口延迟显著升高，完全不能把它当成长期的容量扩容方案。

memory.max字段显示max值，还有必要检查cgroup配置吗？

有必要。这个值只说明当前层级没有设置固定硬上限，但父级cgroup、容器运行时配置或是systemd的其他资源规则仍然可能形成隐性的资源边界；同时事件计数指标也能帮忙确认过去是否发生过内存压力场景。

把容器内存限额提高之后，服务为什么还是会异常重启？

先确认新的资源限额是否真的生效，再核对实际进程内存占用是否还是会被内核选为终止目标。常见的原因包括同个服务内的并发任务数量变多、堆上占用的对象内存从来不会回落，或是节点全局内存压力把受害进程切换成了另外一个进程。

把整套排查流程固化成日常检查项

OOM排查的核心价值不在于记住某一条单独的命令，而在于形成固定的证据链路：用内核日志确认事实，分别从主机维度和cgroup维度定位资源边界，再对照峰值内存预算选择对应改动方案，最后用事件计数和重启次数完成结果复核。下次服务异常退出日志里只留下一个 Killed 报错信息时，顺着这条链路走，一般都能在服务自动重启掩盖现场之前，拿到足够多的有效排查证据。