dmesg -t | grep -i "killed process" 是唯一能原样读取内核 ring buffer 中 oom killer 唯一关键记录的方法，需 root 权限和 -t 参数确保时间可读，输出含 pid、进程名及 anon-rss（实际物理内存占用）等核心指标。
直接看 dmesg -T 是唯一能拿到原始记录的方法
内核只在 ring buffer 里写一次关键日志，dmesg -T 是唯一能原样读到它的工具。加 -T 是为了时间可读——不加就显示 [12345.678901] 这种相对秒数，根本没法和你发现进程挂掉的时间对上。
必须用 root 权限，否则在 RHEL 8+/CentOS 8+ 等系统上默认看不到完整内容（kernel.dmesg_restrict=1）。
- 执行
sudo dmesg -T | grep -i "killed process"，有输出基本就是 OOM Killer 干的 - 没输出 ≠ 没发生，可能是日志被刷掉、权限不够，或根本不是 OOM（比如被
kill -9） - 典型输出：
[Wed Apr 10 09:22:17 2026] Killed process 18942 (python3) total-vm:4567890kB, anon-rss:3214567kB, file-rss:12345kB
anon-rss 才是判断是否真撑爆内存的关键指标
total-vm 是虚拟内存，几乎没参考价值；anon-rss 是进程实际占用的物理内存（不含缓存/映射文件），它接近机器总内存时，基本坐实是它触发了 OOM。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 比如机器有 8GB 内存，
anon-rss:7800000kB≈ 7.8GB → 高概率就是它被选中杀掉的原因 -
file-rss和shmem-rss属于可回收页，一般不参与 OOM 判定 - 容器场景下，
Memory cgroup out of memory这类提示更关键——说明不是整机内存不足，而是某个 cgroup 超限
别只搜关键词，要拉上下文看前因后果
dmesg 只告诉你“谁被杀了”，真正原因藏在前后几秒的日志里。OOM 不是突然发生的，通常伴随这些线索：
-
page allocation failure：内核连一个内存页都分不出去了 -
low memory或free:行：显示各 zone 剩余内存页数，数值极低就是硬扛不住了 - 用
sudo dmesg -T | tail -n 200拉最近 200 行，人工扫一遍 OOM 时间点前后 5 秒内的上下文 - 配合
dmesg -T --level=err,warn聚焦错误与警告，过滤噪音
/proc/PID/oom_score_adj 决定了谁先死，但不是按内存大小拍脑袋
被杀进程不一定是内存最大的那个，而是内核根据 oom_score_adj 综合评估后选定的。这个值越高，越容易被选中。
- 查被杀进程当时的分数：
cat /proc/12345/oom_score_adj（替换为真实 PID） - 对比同类型进程：
ps -eo pid,comm,oom_score,oom_score_adj --sort=-oom_score | head -10 - root 进程默认
oom_score_adj = -1000（免疫），Docker 容器默认设为1000，普通用户进程默认为0 - 注意：
oom_score是实时计算值，oom_score_adj是人为设置的偏移量，两者别混淆
真正难的不是找到那条 Killed process 日志，而是把 anon-rss、oom_score_adj、前后几秒的 page allocation failure 这三块信息串起来——它们各自独立，但合起来才能还原出“为什么偏偏杀它”的完整逻辑。
