dmesg -t | grep -i "killed process"是最准入口，因oom killer仅在内核ring buffer写一次关键记录；输出含pid、进程名及anon-rss（实际物理内存占用），需结合上下文、oom_score_adj和cgroup内存状态综合判断真因。
直接用 dmesg -T 看 OOM Killer 的原始记录
只要进程是被内核 OOM Killer 杀的，dmesg -T 就是最准、最不可替代的入口。它读的是内核 ring buffer，OOM 触发时只写一次关键信息，其他日志工具（如 journalctl 或 /var/log/messages）可能漏掉或延迟落盘。
执行：dmesg -T | grep -i "killed process"
如果输出类似：[Wed Jul 8 10:22:17 2026] Killed process 12345 (java) total-vm:8901234kB, anon-rss:6543210kB, file-rss:45678kB
说明就是 OOM Killer 干的——注意 anon-rss 这个值，它代表该进程实际占用的物理内存（不含文件缓存），单位是 kB；如果接近机器总内存（比如 6.5GB 占了 8GB 总内存的 80%），基本坐实它是“内存肇事者”。
常见坑：
• 没输出 ≠ 没发生：可能是日志被刷掉，或你没 root 权限（RHEL 8+/CentOS 8+ 默认 kernel.dmesg_restrict=1）
• 不加 -T 会看到 [12345.678901] 这种相对时间戳，根本没法和应用崩溃时间对齐
• grep 太窄会漏上下文，建议先跑 dmesg -T | tail -n 200 手动扫 OOM 时间点前后 5 秒内的日志
查 /proc/pid/oom_score_adj 判断为什么选中它
OOM Killer 不是按内存大小拍脑袋杀的，而是算分：每个进程有个 oom_score_adj 值（范围 -1000 到 +1000），数值越高越容易被杀。/proc/<code>pid/oom_score_adj 记录的是该进程当时的得分依据，不是实时动态值，但能帮你确认它是否被“标记”为高风险目标。
操作步骤：
• 从 dmesg 输出拿到被杀进程 PID（比如 12345）
• 执行：cat /proc/12345/oom_score_adj（注意：进程已退出，这个文件只在刚被杀后短暂存在；若已消失，就看不到了）
• 如果返回 0 或正数（比如 300），说明它没被手动保护过；如果返回 -1000，那它本不该被杀——此时要怀疑是不是 kernel bug 或 cgroup 隔离逻辑干扰
补充说明：
• oom_score_adj 可被提前设置（echo -1000 > /proc/<code>pid/oom_score_adj），常用于保护数据库、SSH 等关键服务
• 容器环境里，cgroup 限制比全局内存更优先，oom_score_adj 在容器内可能被覆盖，得结合 /sys/fs/cgroup/memory/ 下对应路径查 memory.usage_in_bytes
确认是不是整机 OOM 还是 cgroup 超限
很多线上问题其实不是服务器内存真不够，而是某个容器或 systemd service 的内存配额被突破，触发了其所属 cgroup 的 OOM ——这种情况下，dmesg 日志里会出现 Memory cgroup out of memory，但不会写明具体容器名或 service 名。
判断方法：
• 先看 dmesg -T | tail -n 200 是否有 cgroup 相关字样
• 如果有，去 /sys/fs/cgroup/memory/ 下找疑似路径（比如 docker-abc123.scope 或 system.slice/myapp.service）
• 查该目录下的：memory.usage_in_bytes（当前用量）、memory.limit_in_bytes（限额）、memory.failcnt（超限次数）
典型现象：
• memory.usage_in_bytes 接近 memory.limit_in_bytes，且 memory.failcnt 在增长 → 是 cgroup 限额导致
• 整机 free -h 显示还有 2GB free，但进程仍被杀 → 基本锁定为 cgroup 问题
• Java 应用常因 JVM 参数（如 -Xmx）设得太大，超出容器内存 limit，触发 cgroup OOM，而非系统级 OOM
别只盯着“被杀”，重点看“杀之前发生了什么”
dmesg 里 “Killed process” 那行只是结果，真正线索藏在它前几秒的日志里。OOM 不是瞬间爆发，而是一连串内存压力信号的终点。
必须检查的上下文关键词：
• page allocation failure：内核连一个页都分配不出，已经彻底卡死
• low memory 或 free: 行：显示各内存 zone 剩余页数，数值为 0 或个位数就是硬扛不住了
• swap Free:：如果 swap 几乎耗尽，说明连交换空间都救不了
• Node X normal: page allocation failure：说明某 NUMA node 内存枯竭，不是全局平均不足
实操建议：
• 用 dmesg -T --level=err,warn 缩小范围，聚焦错误和警告
• 如果系统启用了 kdump，可查 /var/crash/ 下的 vmcore（需额外分析工具）
• 对 Java 进程，同步检查 hs_err_pid*.log 文件是否存在——如果有，说明 JVM 自己崩溃了，不是 OOM Killer 动的手
最后提醒一句：dmesg ring buffer 容量有限，重启后旧日志就没了。生产环境排查时，要么提前配置 rsyslog 把内核日志落盘，要么在复现问题前先执行 dmesg -c 清空缓冲区再开始压测，否则关键记录可能被新日志覆盖掉。
