OOM killer 触发后怎么定位
Linux系统
2026-09-26 17:47
3
进程莫名消失先看内核日志,OOM 会留下完整的击杀记录。命令都会敲,差别在于知不知道每一步在改什么,出问题能不能退回去。
下面按“先判断范围、再处理、最后防复发”的顺序展开,涉及 OOM、内存溢出 的关键动作都给了具体做法,可以照着走。
确认是否 OOM
dmesg -T 或 journalctl -k 搜 Out of memory。
需要留痕的操作,把时间点和现象一起记下来,复盘时最有用。
看被杀进程的占用
日志里有 total-vm 与 rss 数值。
容易踩的坑:变更没留记录,下次故障时没人知道上一轮改了什么。
常见诱因
PHP-FPM 进程数过多、MySQL 缓冲池过大、Java 堆无上限。
出现异常先回退到上一个已知可用状态,再慢慢找原因。
缓解办法
限制单进程内存、加 swap 兜底、分离高内存服务。
常见问题
Q:OOM这类问题,最快的判断办法是什么?
先确认现象的范围:只有单台还是全部、只在某个时段还是持续。范围一缩小,原因基本就浮出来了。
Q:按文中的步骤做完,还需要注意什么?
把处理过程和最终生效的参数记下来。同类问题再出现时直接对照记录,比重查一遍快得多。
小结
回到这篇的四个环节:确认是否 OOM、看被杀进程的占用、常见诱因、缓解办法。生产环境优先考虑稳定性,新参数先在小流量机器上验证。