dmesg -T | grep -i "killed process" 是查看OOM Killer日志最简有效命令，需root权限和-T参数确保时间可读，输出含被杀进程PID、名称及内存指标，anon-rss为关键物理内存占用值。

能直接看到谁被杀了、为什么杀、什么时候杀的，但必须立刻查，晚了就没了。

dmesg -T | grep -i "killed process" 是最简有效命令

OOM Killer 触发后，内核只在 ring buffer 里写一次关键记录，dmesg -T 加时间戳可读性最强。必须用 -T（否则显示相对秒数，难定位），且需 root 权限，否则可能看不到完整内容。

• 常见输出形如：[Wed Apr 10 09:22:17 2026] Killed process 18942 (python3) total-vm:4567890kB, anon-rss:3214567kB, file-rss:12345kB
• 其中 total-vm 是虚拟内存总量，anon-rss 是实际占用物理内存（最关键指标）
• 若无输出，不代表没发生过——可能是缓冲区已被刷掉，或系统限制了非 root 访问（见下一条）

查不到时先检查 dmesg 权限和 ring buffer 是否清空

某些发行版（如 RHEL 8+/CentOS 8+）默认设 kernel.dmesg_restrict=1，普通用户执行 dmesg 只能看到部分日志。

• 临时放开：运行 sudo sysctl kernel.dmesg_restrict=0
• 永久生效：在 /etc/sysctl.conf 加 kernel.dmesg_restrict=0，再 sudo sysctl -p
• 若怀疑日志被覆盖，立即执行 sudo dmesg -c 清空缓冲区，再复现问题（比如跑 stress --vm 1 --vm-bytes 3G）
• 注意：dmesg -c 会清空所有未读日志，慎用于生产环境

单靠 killed process 不够，得看上下文和内存状态

dmesg 只告诉你“结果”，不解释“原因”。同一时间点前后几秒的日志往往藏着线索：页分配失败、内存压缩压力、cgroup 超限等。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 用 sudo dmesg -T | tail -n 200 查最近 200 行，人工找 Out of memory 前后的 page allocation failure、low memory、free: 行
• 配合 cat /proc/meminfo | grep -E "(MemAvailable|SwapFree|Committed_AS)" 看当时真实可用内存
• 如果进程在容器里，cat /sys/fs/cgroup/memory/.../memory.limit_in_bytes 和 memory.usage_in_bytes 才是真正触发点，dmesg 不会体现 cgroup 边界

被杀进程的 oom_score_adj 值决定它是不是“替死鬼”

分数高 ≠ 内存最大，而是内核综合评估后认为“杀它代价最小”。这个权重由 /proc/[pid]/oom_score_adj 控制，范围是 -1000 到 +1000。

• 查被杀进程当时的值：sudo cat /proc/18942/oom_score_adj（替换为实际 PID）
• 对比同类进程：ps -eo pid,comm,oom_score_adj --sort=-oom_score_adj | head -10
• root 进程默认 -1000（免疫），Docker 容器默认 +1000（优先杀），Java 应用常被手动设高分以保其他服务
• 注意：该文件只在进程存活时可读；若进程已退出，只能靠 dmesg 记录里的 PID 去查历史快照（如有）

ring buffer 天生易失，dmesg 是第一响应工具，不是归档方案。真要长期追踪，得配 rsyslog 持久化 kern.* 到 /var/log/kern.log，或者用 journalctl -k 配合 --since 回溯——否则下次重启，连“它到底有没有被杀过”都成谜。