OOM事件发生时，内核会在ring buffer中记录关键信息，使用dmesg -T | grep -i "killed process\|out of memory"可精准定位；日志含PID、进程名、内存占用及时间戳，需结合dmesg -T | tail -200查看上下文，并通过/proc/PID/oom_score_adj分析被杀依据。
在Linux系统中，当内存严重不足时，内核的OOM（Out-Of-Memory） killer会主动终止某些进程以保障系统基本运行。这类终止不会留下常规日志（如syslog或journalctl中的用户级记录），但会在内核环缓冲区（kernel ring buffer）中输出明确信息，dmesg正是查看这些信息最直接有效的工具。
确认OOM事件是否发生
执行以下命令，筛选包含“Out of memory”或“Killed process”的内核消息：
dmesg -T | grep -i "killed process|out of memory"
若存在OOM触发，通常会看到类似这样的输出：
- [Wed Jan 10 14:22:37 2024] Out of memory: Kill process 12345 (java) score 894 or sacrifice child
- [Wed Jan 10 14:22:37 2024] Killed process 12345 (java) total-vm:12345678kB, anon-rss:8765432kB, file-rss:12345kB
其中包含被杀进程的PID、命令名、内存占用详情及触发时间（-T选项显示本地可读时间）。
查看更完整的OOM上下文
单靠关键词可能漏掉前因（如内存分配失败、页回收压力等）。建议用以下方式扩大观察范围：
- 用 dmesg -T | tail -n 200 查看最近200行内核日志，人工定位OOM前后几秒的内存相关提示（如“page allocation failure”、“low memory”、“free:”统计）
- 配合 dmesg -T --level=err,warn 聚焦错误与警告，提高排查效率
- 若系统启用了kdump或保存了早期内核日志，可用 dmesg -T -F /var/log/kern.log（需对应日志文件存在且格式兼容）读取归档内容
理解OOM killer的决策依据
被杀进程不一定是内存最大的那个，而是由内核根据oom_score_adj值综合评估后选定的。可通过以下方式辅助分析：
- 查被杀进程当时的oom_score_adj：cat /proc/12345/oom_score_adj（替换12345为实际PID）
- 对比同类型进程的分数：ps -eo pid,comm,oom_score,oom_score_adj --sort=-oom_score | head -10，分数越高越容易被选中
- 注意：root进程默认oom_score_adj = -1000（免疫），普通用户进程默认为0，容器或服务可能被手动调高（如Docker默认设为1000）
后续处理建议
仅查看日志不够，需结合系统状态做判断和优化：
- 检查内存使用趋势：free -h、cat /proc/meminfo，重点关注MemAvailable、SwapFree
- 确认是否有内存泄漏或配置不当：如JVM堆设得过大、MySQL buffer_pool过载、未限制容器内存上限等
- 临时缓解可增加swap（仅限测试环境），长期应调整应用内存配置、升级物理内存，或通过cgroup限制关键进程内存使用
