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 只能看到部分日志。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 临时放开：运行
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 超限等。
- 用
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 回溯——否则下次重启，连“它到底有没有被杀过”都成谜。
