进程半夜神秘消失？4步揪出OOM Killer真凶
摘要： 凌晨进程莫名消失，日志只剩一行 Out of memory。多数人本能反应是又宕机了、重启就好------结果明天同一负载又杀一遍。本文用 4 步法，从确认到根治，每一步讲清"为什么这么查"，附可直接抄的命令。防汛防台巡检期，机房偏偏怕这种不告警只杀进程的慢病。
一、先别急着重启：是"OOM"不是"宕机"
看到进程列表里服务不见了，多数人的本能反应是：又宕机了，重启就好。看着恢复了，以为稳了------结果过会儿又没了。
讲真的，OOM Killer 和宕机根本不是一回事。宕机是进程自己挂了或被人误删；OOM Killer 是 Linux 内核在内存不够时，挑一个占内存大的进程杀掉，保住系统不整体崩。重启只是腾出空间，根因（谁在吃内存）没动，所以还会再来。
防汛防台巡检期，机房恰恰怕这种不告警只杀进程的慢病，它比硬件坏更隐蔽，监控上进程一直是绿的。
二、诊断3板斧：确认、定位、判类型
① 确认是不是 OOM
dmesg | grep -i 'killed process'
# 看内核有没有杀进程记录有这行就是 OOM，不是应用自己崩，方向完全不同------别白重启服务。
为什么这么查： OOM Killer 的痕迹只在内核日志 dmesg 里，应用层日志看不到。先定性，才知道往哪使劲。
② 定位谁吃的
ps aux --sort=-%mem | head
# 或 top，按内存排序看排前面的进程找到那个把内存吃满的主儿，是 Java 还是某个常驻脚本。
**为什么这么查：**OOM 杀的是"占内存大"的进程，所以直接按内存排序，凶手排在第一位。别猜，看数据。
③ 判类型
是内存泄漏慢慢涨，还是配置开太大（堆/缓存），还是容器 limit 太小。
**为什么这么查：**类型不同治法不同。泄漏要修代码，配置大要调小，limit 小要放大并留余量。乱加内存只会拖延。
| 步骤 | 看什么 | 指向的根因 |
|---|---|---|
| ① 确认 | dmesg 有无 killed process | OOM，不是应用崩 |
| ② 定位 | ps 按内存排序 / top | 谁占内存大 |
| ③ 判类型 | 泄漏 / 配置 / limit | 治法完全不同 |
三、第4步：先止血后根治
④ 先止血
- 临时加
swap腾出缓冲； - 调
oom_score_adj保命（降低被杀优先级）； - 给进程限内存上限；
- 先让服务活下来。
**为什么分两步：**先止血是为了争取时间，别一边查一边业务一直挂。
⑤ 再根治
- 修内存泄漏，关掉涨的那块；
- 把过大的堆 / 缓存配置调小；
- 容器
limit设合理并留余量； - 给内存设告警阈值。
为什么分两步： 加 swap 只是腾缓冲，根因不除第二天还来。调小配置、修泄漏才是治本。
当然也有人不这么想，觉得加机器堆配置就行。可内存泄漏是代码层面的"只涨不收"，加机器只是让每个机器都漏，白搭。
四、真实复盘：上个月我踩的坑
上个月我自己就踩了一次：加了 4G swap，重启服务看着正常，关机睡觉，结果第二天又被杀了。后来一查，是某段缓存逻辑没上限，内存慢慢涨满------我加的是磁盘 swap，它漏的是进程里的内存。把缓存逻辑加上限，才真稳。
当时我反复确认了好几遍，差点以为中邪了。这事儿给我一个提醒：半夜这种告警，光靠脑子记容易漏，得有个地方把谁接了、查到哪步记下来。
五、防复发：让系统反脆弱
做了几年运维，我越来越觉得，含金量不在你会多少命令，在于每一次故障能不能变成下次能复盘的档案。这次 OOM，根因是什么、谁处理的、花了多久，记下来，下回同类问题十分钟能灭。每次处置沉淀成预案，下次同类告警直接照着走，基础设施更抗造------这就是让系统反脆弱。
想偷懒，找个能接企业微信、告警自动建单的系统，比如宝企通运维工单，省得半夜靠脑子记。只是顺带一提，不急着买，先把思路理顺。
#Linux运维#OOM#内存溢出#故障排查#运维
如果你正好在搜 中小企业工单系统哪家好用 ，可以关注我，后面再聊 SaaS工单系统哪家性价比高。你被 OOM 坑过几次？评论区扣个数字，我发你一张排障命令卡。