直接查dmesg日志确认oom killer杀进程：执行dmesg | grep -i "out of memory\|oom\|killed process"，若输出含“killed process pid (name) anon-rss:xxxkb”即坐实；再结合/var/log/messages等系统日志、free -h内存状态及ps aux --sort=-%mem交叉验证，排除kernel panic干扰。
直接看内核日志，重点找 OOM Killer 杀进程的痕迹。Linux 不会在应用日志里写“我被杀死了”，而是由内核在内存耗尽时主动干预，日志全留在系统底层。
查 dmesg 环形缓冲区（最快速）
运行命令：
dmesg | grep -i "out of memory|oom|Killed process"
如果输出类似：
Out of memory: Kill process 12345 (java) score 894 or sacrifice childKilled process 12345 (java) total-vm:3245678kB, anon-rss:1890123kB, file-rss:0kB
说明就是 OOM 导致进程被杀。注意看 score（内核评分）、total-vm（虚拟内存）、anon-rss（实际占用物理内存）这些关键数值。
翻系统日志文件（更完整时间线）
OOM 触发后，日志可能已刷入持久化文件：
-
grep -i "oom" /var/log/messages（CentOS/RHEL） -
grep -i "oom" /var/log/syslog（Ubuntu/Debian） -
grep -i "oom" /var/log/kern.log（专收内核消息）
这些日志通常包含：触发时间、被杀进程名与 PID、当时内存水位、Swap 使用情况，能帮你确认是不是反复发生、是否集中在某时段或某服务启动后。
结合内存状态交叉验证
单看日志不够，要同步检查当时内存是否真的耗尽：
- 运行
free -h：关注 used 接近 total、swap used 非零且较高 - 运行
cat /proc/meminfo | grep -E "MemAvailable|MemFree|SwapFree"：看可用内存是否低于几百 MB - 运行
ps aux --sort=-%mem | head -10：找出当前内存大户，对比日志里被杀的进程是否一致
若日志显示 OOM，但 free 显示内存充足，可能是容器环境未正确暴露 cgroup 内存限制，或应用本身存在 native 内存泄漏（如 JVM Direct Memory、Python C 扩展），需进一步用 pmap -x <pid></pid> 或 jemalloc 工具深挖。
排除内核崩溃干扰（避免误判）
有些重启看起来像 OOM，其实是 Kernel Panic。别混淆，用以下命令区分：
-
dmesg | grep -i "panic|oops|bug"—— 出现 Kernel panic - not syncing 就不是 OOM -
ls /var/crash/—— 有 vmcore 文件说明发生了内核崩溃 -
journalctl -k --since "2 hours ago" | grep -i "kill|oom|panic"—— systemd 日志中同时出现两类关键词？要仔细比对时间戳
OOM 是内核“有意识地杀进程保系统”，Kernel Panic 是内核“自己崩了没法干活”。前者日志干净利落，后者常伴随调用栈、寄存器 dump 和硬件报错。
