dmesg -T 是唯一能原样读取 OOM Killer 触发时“Killed process”记录的工具，需 root 权限且应结合 anon-rss、上下文日志及 oom_score_adj 综合分析根因。
直接看 dmesg -T 输出里的 “Killed process”
OOM Killer 触发后，内核只在 ring buffer 写一次关键记录，dmesg -T 是唯一能原样读到它的工具。加 -T 是为了时间可读——不加就是 [12345.678901] 这种相对秒数，根本没法和你发现进程消失的时间对上。
执行命令：
dmesg -T | grep -i "killed process"
典型输出形如：
[Wed Jul 3 14:22:17 2026] Killed process 23456 (node) total-vm:3214567kB, anon-rss:2890123kB, file-rss:12345kB
重点看 anon-rss：它代表该进程实际占用的物理内存（不含缓存/映射文件），比 total-vm 更能说明问题。如果这个值接近机器总内存（比如 32G 机器上看到 2.8G+），基本坐实是它撑爆了系统。
注意：dmesg -T 需要 root 权限才能在 RHEL 8+/CentOS 8+ 等系统看到完整内容（kernel.dmesg_restrict=1 默认启用）。没输出不等于没发生，可能是日志被刷掉或权限不够。
查不到 "killed process"？先确认三件事
不是没发生，而是日志丢了或被截断。优先检查：
-
sudo sysctl kernel.dmesg_restrict，若返回1，说明非 root 用户被限制访问——临时放开：sudo sysctl kernel.dmesg_restrict=0 - 执行
sudo dmesg -c清空缓冲区（注意：会丢掉所有未读日志，生产环境慎用），再复现问题（比如跑stress --vm 1 --vm-bytes 3G） - 查
/var/log/messages或journalctl -k：sudo grep -i "out of memory\|killed process" /var/log/messages，部分发行版会把 OOM 日志落盘
光看“被杀”不够，得拉上下文看“为什么杀”
dmesg 只告诉你结果，真正原因藏在前后几秒的日志里。OOM 不是突然发生的，通常伴随这些线索：
-
page allocation failure：内核连一个内存页都分不出去了 -
low memory或free:行：显示各 zone 剩余内存页数，数值极低就是硬扛不住了 - 如果是容器：
Memory cgroup out of memory这种提示更关键——说明不是整机内存不足，而是某个 cgroup 超限；dmesg不会显示具体容器名，得去查/sys/fs/cgroup/memory/<cgroup-id>/memory.usage_in_bytes
所以别只搜关键词，用 sudo dmesg -T | tail -n 200 拉最近 200 行，人工扫一遍 OOM 时间点前后 5 秒内的上下文。
oom_score_adj 才是决定谁先死的开关
被杀进程不一定是内存最大的那个，而是由内核根据 oom_score_adj 值综合评估后选定的。这个值越高，越容易被选中。
查被杀进程当时的分数（替换 PID）：
cat /proc/23456/oom_score_adj
对比同类型进程的分数：
ps -eo pid,comm,oom_score,oom_score_adj --sort=-oom_score | head -10
注意：root 进程默认 oom_score_adj = -1000（免疫），普通用户进程默认为 0，Docker 容器默认设为 1000，有些服务启动时还会手动调高（比如 systemd 启动的服务可能设为 300）。分数不是静态的，它会随内存压力动态变化，但初始设置影响极大。
真正难搞的是那些 oom_score_adj 被调高、又确实占内存的进程——它们既容易被杀，又不好随便改配置。这时候得结合 anon-rss 和 cgroup 边界一起看，否则光调分数只是掩耳盗铃。
