dmesg -T | grep -i "killed process" 是查看OOM Killer日志最简有效命令，需root权限和-T参数确保时间可读，输出含PID、进程名及anon-rss等关键内存指标，但必须结合上下文和/proc/meminfo等进一步分析根因。
直接用 dmesg -T | grep -i "killed process" 就能看到内核因物理内存不足而触发 OOM Killer 杀掉进程的记录，但得注意权限、时间格式和上下文，否则容易漏判或误读。
核心命令与权限要求
执行以下命令获取可读性强、定位准的日志：
-
必须加 -T 参数：显示本地可读时间（如
[Tue Apr 28 10:33:22 2026]），不加则输出秒级相对时间，难以对应业务异常时刻 -
需 root 权限：普通用户可能被限制访问完整 ring buffer，尤其在 RHEL 8+/CentOS 8+ 等系统上，默认
kernel.dmesg_restrict=1 - 若无输出，先检查是否受限：
sudo sysctl kernel.dmesg_restrict；临时放开用sudo sysctl kernel.dmesg_restrict=0，永久生效写入/etc/sysctl.conf并运行sudo sysctl -p
识别关键日志特征
典型 OOM 杀进程行包含三项硬指标：
-
PID 和进程名：如
Killed process 24567 (node)，明确谁被终止 -
anon-rss 值：如
anon-rss:1894567kB，这是实际占用的物理内存（不含缓存/页缓存），是判断“吃内存大户”的核心依据 - total-vm 与 file-rss：前者是虚拟内存总量，后者是文件映射页缓存，辅助判断内存类型分布
示例完整行：[Mon Apr 27 22:15:08 2026] Killed process 24567 (node) total-vm:8245678kB, anon-rss:1894567kB, file-rss:45678kB
不能只看单行，要查上下文
OOM 是结果，不是起点。单靠 “Killed process” 行无法定位根本原因，必须扩大范围看前因：
- 用
sudo dmesg -T | tail -n 200查最近 200 行，人工找 OOM 时间点前后几秒的关键线索 - 重点关注：
Out of memory（总触发标志）、page allocation failure（页分配失败）、low memory、free:开头的内存统计行 - 配合
cat /proc/meminfo | grep -E "(MemAvailable|Committed_AS|SwapFree)"看当时真实可用内存和已承诺内存
结合 oom_score_adj 判断“为什么杀它”
被杀进程不一定是内存最大者，而是内核综合评估后认为“杀它代价最小”的那个：
- 查该进程当时的调整值：
sudo cat /proc/24567/oom_score_adj（替换为实际 PID） - 分数范围是 -1000（root 进程免疫）到 +1000（如 Docker 容器默认高分，优先牺牲）
- 对比同类进程：
ps -eo pid,comm,oom_score_adj --sort=-oom_score_adj | head -10，看是否被人为调高过
如果进程在容器中，真正触发点是 cgroup 边界：cat /sys/fs/cgroup/memory/<cgroup-path>/memory.limit_in_bytes</cgroup-path> 和 memory.usage_in_bytes 才是决定性指标，dmesg 不会体现这些。
