直接查/var/log/syslog或/messages中oom killer记录是判断系统因swap耗尽或内存压力过大而杀进程的关键证据，需结合dmesg、journalctl、grep命令定位日志，并通过/proc/meminfo、cgroup限制及slabtop等交叉验证真实原因。
直接查 /var/log/syslog 或 /var/log/messages 中的 OOM Killer 记录，这是系统因 swap 耗尽或内存压力过大而强制终止进程的关键证据。
查 OOM Killer 触发日志
执行以下命令，筛选出内核主动杀进程的记录：
- dmesg -T | grep -i "killed process" —— 查看带时间戳的实时内核日志，最直接反映哪次卡顿触发了进程回收
- journalctl -b | grep -i "out of memory" —— 检索本次启动以来所有 OOM 相关条目，包括“Out of memory: Kill process”和“sacrifice child”等关键词
- grep -i "killed process" /var/log/syslog（Ubuntu/Debian）或 grep -i "killed process" /var/log/messages（RHEL/CentOS）—— 查看持久化日志文件
结合内存状态交叉验证
单看“killed process”还不够，需确认当时是否真因 swap 耗尽或内存枯竭：
- 在查到 OOM 时间点后，运行 cat /proc/meminfo，重点关注 MemAvailable（可用内存）和 SwapTotal / SwapFree —— 若 SwapFree 接近 0 且 MemAvailable 极低（如
- 用 free -h 回溯历史快照（如有监控留存）或结合 vmstat 1 观察 so（swap out）是否持续 >0、swpd 是否快速涨满
注意区分“假性 OOM”场景
不是所有“killed process”都源于全局内存不足，有些是局部资源受限：
- 检查是否为容器或 systemd service：运行 ls /sys/fs/cgroup/memory/，进入对应子目录查看 memory.limit_in_bytes 和 memory.usage_in_bytes，若 usage 接近 limit，说明是 cgroup 配额被突破，而非系统级 swap 耗尽
- 排查 slab 泄漏：运行 slabtop -o，关注 dentry、size-4096 等项占比是否超 60%，这类内核缓存未释放也会挤占可用内存，诱发误报 OOM
补充：swap 耗尽前的预警信号
卡顿往往发生在 swap 写满前几秒，可提前捕获迹象：
- vmstat 1 中持续出现 so > 0 且 wa%（I/O 等待）明显升高（>20%），说明系统正疯狂往磁盘 swap 写数据
- iostat -x 1 显示 %util ≈ 100% + await > 10ms，尤其伴随 r/s 或 w/s 异常突增，表明 swap 所在磁盘已成瓶颈
