确认oom killer杀进程需执行dmesg -t | grep -i "killed process"，有输出基本可定；无输出可能是日志丢失、权限不足或非内核触发，须结合sysctl kernel.dmesg_restrict、journalctl -k及oom上下文综合判断。
直接看 dmesg -T | grep -i "killed process"，有输出基本就是 OOM Killer 干的；没输出不等于没发生，可能是日志被刷掉、权限不够，或根本不是内核杀的。
怎么确认是 OOM Killer 杀的
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 Linux Hardware Debug
下载
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 才是开关
被杀进程不一定是内存最大的那个，而是由内核根据 oom_score_adj 值综合评估后选定的。这个值越接近 1000，越容易被选中。
- 查被杀进程当时的评分：
cat /proc/12345/oom_score_adj（替换 12345 为实际 PID） - 该值可被手动调整（如
echo -500 > /proc/12345/oom_score_adj），但仅对当前运行有效；持久化需通过 systemd 的OOMScoreAdjust=配置项 - 注意：容器 runtime（如 docker、podman）默认会设置负值降低其内进程被杀概率，但若 cgroup memory limit 设得太紧，仍可能触发 cgroup-level OOM，此时
dmesg日志里不会出现 PID，只有 cgroup 路径
真正难搞的不是“有没有被杀”，而是“为什么偏偏杀它”。oom_score_adj 和 cgroup 边界共同决定命运，而这两者往往在部署时就被静默设定了，事后很难回溯。别只盯着最后一行日志，得把前 200 行当连续剧看。
