dmesg -t | grep -i "killed process" 是诊断oom killer的首选方法，因其直接读取内核ring buffer中唯一一次的关键记录，-t提供可读时间戳，且需root权限才能在rhel 8+/centos 8+等系统查看完整日志。
直接看 dmesg -T | grep -i "killed process"，有输出基本就是 OOM Killer 干的；没输出不等于没发生，可能是日志被刷掉或权限不够。
为什么 dmesg -T | grep "killed process" 是第一反应
OOM Killer 触发时只在内核 ring buffer 写一次关键记录，dmesg 是唯一能原样读到它的工具。加 -T 是为了时间可读——不加就显示“[ 12345.678901]”这种相对秒数，根本没法和应用崩溃时间对齐。必须用 root 权限，否则在 RHEL 8+/CentOS 8+ 等系统上默认看不到完整内容（kernel.dmesg_restrict=1）。
常见输出形如：
[Wed Apr 10 09:22:17 2026] Killed process 18942 (python3) total-vm:4567890kB, anon-rss:3214567kB, file-rss:12345kB
其中 anon-rss 是关键：它代表该进程实际占用的物理内存（不含缓存/映射文件），比 total-vm（虚拟内存）更能说明问题。如果这个值接近机器总内存，基本坐实是它撑爆了系统。
查不到 "killed process" 怎么办
不是没发生，而是日志丢了或被截断。优先检查三件事：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行
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，虽然不如dmesg及时，但部分发行版会把 OOM 日志落盘：sudo grep -i "out of memory\|killed process" /var/log/messages
光看“被杀”不够，得看“为什么杀”
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</cgroup-id>
所以别只搜关键词，用 sudo dmesg -T | tail -n 200 拉最近 200 行，人工扫一遍 OOM 时间点前后 5 秒内的上下文。
oom_score_adj 才是决定谁先死的开关
被杀进程不一定是内存最大的那个，而是内核综合评估后认为“杀它代价最小”的那个。这个权重由 /proc/[pid]/oom_score_adj 控制，范围 -1000 到 +1000：
- root 进程默认 -1000（免疫），Docker 容器默认 +1000（优先杀）
- 查被杀进程当时的值：
sudo cat /proc/18942/oom_score_adj（替换为真实 PID） - 对比同类进程：
ps -eo pid,comm,oom_score_adj --sort=-oom_score_adj | head -10，看它是不是被明显调高过
很多人忽略一点：oom_score_adj 是动态的，启动时设了 -500，不代表运行中没被其他组件（比如 systemd、dockerd）悄悄改回 0 或更高。所以查日志时一定要带 PID 锁定具体时刻的值。
