首选dmesg -T | grep -i "killed process"定位OOM Killer证据，因其直接读取内核ring buffer中唯一关键记录；无输出需排查日志清空、权限限制或重启丢失，并辅以journalctl和上下文分析。
直接看 dmesg -T 输出，这是最可靠、最原始的证据来源。OOM Killer 只在内核 ring buffer 里写一次关键记录，dmesg 是唯一能原样读取它的工具。
用 dmesg 快速定位 OOM 杀进程记录
执行以下命令：
dmesg -T | grep -i "killed process"
如果输出类似这样：
[Wed Oct 7 22:15:33 2026] Killed process 8921 (node) total-vm:2456789kB, anon-rss:1823456kB
就基本坐实是 OOM Killer 干的。注意时间戳是否和你发现进程消失的时间接近。
若没匹配到，别急着排除 OOM，可能原因有：
- 日志已被清空（如执行过 dmesg -c）
- 非 root 用户被限制访问：运行 sudo sysctl kernel.dmesg_restrict，若返回 1，则需临时放开：sudo sysctl kernel.dmesg_restrict=0
- 系统重启后部分日志丢失（ring buffer 是易失的）
查落盘日志作为补充证据
即使 dmesg 没结果，也建议检查持久化日志：
sudo grep -i "out of memory\|killed process" /var/log/messages
或（较新系统）：
sudo journalctl -k --grep="oom\|killed process" --since "24 hours ago"
这些日志可能比 dmesg 更完整，尤其当问题发生在较早时间且未重启时。
看上下文才能判断“为什么杀”
单看 “Killed process” 行不够。OOM 不是突袭，通常前几秒就有预警信号：
- 出现 page allocation failure 或 low memory 提示
- 看到 free: 行，显示各内存 zone 剩余页数极低（如
free: 12） - 如果是容器环境，留意 Memory cgroup out of memory —— 这说明是 cgroup 内存超限，不是整机缺内存
推荐执行：sudo dmesg -T | tail -n 200，人工扫一遍 OOM 时间点前后 5 秒内的上下文。
查被杀进程当时的内存真实占用
OOM 杀的是 anon-rss 高的进程，这个值代表它实际占着的物理内存（不含缓存/文件映射）。确认泄漏或异常占用，得看更细的指标：
-
VmRSS：查 /proc/
/status 中的 VmRSS 字段（单位 KB） -
USS：查 /proc/
/smaps 中Private_Clean + Private_Dirty之和，这才是该进程独占、不可共享的物理内存
比如怀疑 Python 进程泄漏，可结合 tracemalloc 抓堆栈；Java 进程则用 jmap -histo 看对象分布。
