直接用dmesg -t | grep -i "killed process|out of memory"可抓取oom killer杀进程的核心记录，但需结合上下文（如page allocation failure）、内存状态（/proc/meminfo）和oom_score_adj值综合分析被杀原因与系统压力。
直接用 dmesg -T | grep -i "killed process\|out of memory" 就能抓到 OOM Killer 杀进程的核心记录，但要真正看懂“谁被杀、为什么杀、系统当时多紧张”，得配合时间、上下文和内存状态一起看。
快速定位杀进程的原始日志
OOM 事件发生后，内核只在 ring buffer 写一次关键信息，不持久化。必须立刻执行：
- sudo dmesg -T | grep -i "killed process\|out of memory" —— 最简有效命令，-T 输出本地可读时间（如 [Wed Apr 10 09:22:17 2026]），避免相对秒数难定位
- 典型输出含：PID、进程名（如 python3）、total-vm（虚拟内存）、anon-rss（真实物理内存占用，最关键）
- 若无输出，不是没发生，而是缓冲区已被刷掉，或普通用户权限受限（RHEL/CentOS 8+ 默认 kernel.dmesg_restrict=1）
查上下文：光看“被杀”不够，要看“为啥杀”
OOM 是结果，不是起点。前几秒往往有页分配失败、内存压缩压力等线索：
- sudo dmesg -T | tail -n 200 —— 查最近 200 行，人工找 “Out of memory” 前后的 page allocation failure、low memory、free: 等关键词
- sudo dmesg -T --level=err,warn | tail -50 —— 聚焦错误与警告，过滤噪音
- 若系统启用了 kdump 或 syslog 归档，可补查：sudo journalctl -k --grep="oom\|out.of.memory" --since="2 hours ago"
结合内存状态交叉验证
单看 dmesg 是“断案”，查 /proc 才算“验尸”：
- 运行时执行：cat /proc/meminfo | grep -E "(MemAvailable|SwapFree|Committed_AS)" —— 看当时真实可用内存是否已见底
- 若进程在容器中：cat /sys/fs/cgroup/memory/xxx/memory.limit_in_bytes 和 memory.usage_in_bytes 才是触发点，dmesg 不体现 cgroup 边界
- 查内存压力：cat /proc/pressure/memory —— 若 avg10 长期 > 5，说明系统持续承压
分析被杀依据：不是内存最大，而是“最该杀”
内核选进程靠 oom_score_adj 综合评估，不是简单比 RSS：
- 查被杀进程当时的调整值：sudo cat /proc/18942/oom_score_adj（替换为实际 PID）
- 对比同类进程：ps -eo pid,comm,oom_score_adj --sort=-oom_score_adj | head -10
- 注意默认规则：root 进程 = -1000（免疫），Docker 容器默认 +1000（优先杀），Java 应用常被手动设高分保其他服务
