OOM 被杀进程怎么排查
进程「莫名消失」或服务被系统杀掉时，第一件事是确认是否发生过 OOM：内核在内存耗尽时会按评分选择进程终止，并把过程写进内核日志，dmesg、messages 与 journalctl -k 都能查到 Out of memory 与 killed process 记录。确认之后再区分是应用内存增长、并发突增还是配额偏小，并同时给应用设置内存上限，否则扩容只是把问题推迟。
基本信息
| 内核日志 | dmesg -T、/var/log/messages、journalctl -k |
|---|---|
| 关键词 | out of memory、oom-killer、killed process |
| 当前状态 | free -h 查看内存与交换使用 |
| 内存排行 | ps aux --sort=-%mem | head |
| 上限设置 | systemd 的 MemoryMax 或 JVM 的 Xmx 参数 |
典型使用场景
- 应用进程突然消失且无退出日志，需要确认是否被内核杀掉
- 服务频繁重启，怀疑与内存超限有关，需要找到证据
- 容器运行环境的 OOM 排查，需同时核对容器与宿主机两层限制
- 容量规划：根据历史内存曲线评估是否需要扩容
- 排查内存持续增长类问题，区分泄漏与正常缓存增长
- 上线前为服务设置合理上限，避免单服务影响整机
确认与对策
确认与对策
dmesg -T | grep -iE 'out of memory|oom|killed process' | tail -20 # 内核日志
grep -i oom /var/log/messages* 2>/dev/null | tail -20
journalctl -k -b | grep -i oom | tail -20 # 本次启动的内核消息
free -h # 当前内存与交换使用
ps aux --sort=-%mem | head -10 # 内存占用排行
sysctl vm.overcommit_memory # 查看超分策略
cat /proc/meminfo | head -20 # 内存细分信息
# 长期对策：给服务设上限（systemd 用 MemoryMax，Java 用 -Xmx）
# systemctl show app-web -p MemoryMax证据与判读
| 证据来源 | 能看到什么 | 判读要点 |
|---|---|---|
| dmesg -T | 带时间戳的内核消息 | 确认被杀进程名与总内存水位 |
| messages 日志 | 持久化的系统消息 | 重启后仍可回查 |
| journalctl -k | 按启动批次的内核日志 | 区分是哪一次启动发生 |
| free -h | 当前内存与交换占用 | 判断是否长期处于高位 |
| 内存排行 | 占用最高的进程 | 找增长型应用或异常进程 |
不要用重启掩盖问题：先分清是应用增长、并发突增还是资源配额偏小，加内存之前先给应用设置内存上限，否则问题会周期性复发。
容器环境的 OOM 要分两层核对：容器自身的限制被触发时也会杀掉进程，此时宿主机内存可能并不紧张，只看宿主机指标会得出错误结论。