dmesg -t | grep -i "killed process"是诊断oom killer的首选方法，因其直接读取内核ring buffer中唯一一次的关键记录，需root权限和-t参数确保时间可读，输出含pid、进程名及anon-rss等关键内存指标，但必须结合上下文和/proc/meminfo等进一步分析根因。
直接看 dmesg -T 有没有 “Killed process” 记录
有，基本就是 OOM Killer 干的；没有，不代表没发生，可能是日志被刷掉、权限不够或根本不是内核杀的。dmesg -T 是唯一能原样读到内核 ring buffer 中那条关键记录的工具，其他日志（比如 /var/log/messages）是二次落盘，可能延迟、丢失或不全。kernel.dmesg_restrict=1（RHEL 8+/CentOS 8+ 默认开启）会阻止非 root 用户看到完整内容，所以必须加 sudo。
重点盯住 anon-rss 和前后几秒的上下文
anon-rss 值才是真·物理内存占用，比 total-vm 有用得多。如果它接近机器总内存（比如 64G 机器上显示 anon-rss:62345678kB），基本坐实是它撑爆了系统。但光看这一行不够——OOM 不是瞬间触发的，得拉出前后日志：sudo dmesg -T | grep -A10 -B10 "Killed process"。重点关注：
-
page allocation failure：内核连一个页都分不出来了 -
low memory或free:行：各内存 zone 剩余页数极低 -
Memory cgroup out of memory：说明是容器或 systemd service 超限，不是整机问题
查不到 "killed process"？先确认三件事
别急着翻 /var/log/messages 或 journalctl，先做这三步排查：
- 运行
sudo sysctl kernel.dmesg_restrict，返回1就说明被限制，临时放开：sudo sysctl kernel.dmesg_restrict=0 -
sudo dmesg -c清空缓冲区（生产环境慎用），再复现问题（比如跑stress --vm 1 --vm-bytes 3G） - 查落盘日志：
sudo grep -i "out of memory\|killed process" /var/log/messages（CentOS/RHEL）或/var/log/syslog（Ubuntu/Debian）
退出码 137 是重要线索，但不能只信它
echo $? 返回 137，代表收到了 SIGKILL（信号 9），但来源不一定是 OOM Killer——也可能是 kill -9、systemd 强制 stop、或容器 runtime 杀的。这时候要交叉验证：journalctl -u your-service.service -n 50 看有没有 Stopping 或 KillMode=control-group 相关记录；如果是容器，docker inspect 容器ID | grep -i oom 更直接。真正容易被忽略的是：OOM Killer 日志里从不提容器名或 service 名，只写 PID 和进程名，得靠 ps -o pid,comm,args -p PID 手动反查。
