Linux OOM 本质是内存耗尽后内核强制终止进程，排查关键在于厘清压力来源、识别真实瓶颈、验证是否误杀；需分析 OOM 日志定位被杀进程与触发条件，分层验证内存使用，深挖进程内存增长源头，并实施临时缓解与长期治理措施。
Linux OOM（Out of Memory）问题本质是系统内存耗尽后，内核触发 OOM Killer 强制终止进程来保全系统。排查关键不在于“找哪个进程占内存最多”，而在于厘清内存压力来源、识别真实瓶颈、验证是否误杀关键服务。
看懂 OOM 日志：定位被杀进程和触发条件
系统触发 OOM 时，内核会在 dmesg 或 /var/log/kern.log 中输出完整日志。重点抓三类信息：
- 时间戳与触发上下文：确认 OOM 发生时刻，结合业务日志判断是否有批量任务、流量突增或定时作业
- “Killed process XXX (pid YYY)”行 ：明确被终止的进程名、PID、UID，注意不是最高 RSS 的进程，而是 oom_score_adj 值最高且 内存占用 大的“综合得分最高者”
- “Mem-Info”快照 ：查看 Active/Inactive(anon)、SwapCached、PageTables 等字段，判断是匿名页（堆 / 栈）、页表开销还是缓存膨胀导致压力
查内存真实使用：别只盯 free -h
free 命令显示的“available”是估算值，易误导。需分层验证：
- cat /proc/meminfo | grep -E “(MemTotal|MemFree|MemAvailable|Buffers|Cached|SReclaimable|SwapTotal|SwapFree|Committed_AS|CommitLimit)”：重点关注 Committed_AS（已承诺 虚拟内存）是否接近 CommitLimit，超限即可能 OOM
- slabtop -o：检查内核 slab 分配器是否泄漏（如 dentry、inode、ext4_inode_cache 异常增长）
- smem -w -k -c “pid user command swap pss uss” | head -20：按 PSS（比例集大小）排序，比 RSS 更准确反映进程实际内存贡献
分析内存增长源头：从进程到应用层
确认某进程持续吃内存后，不能直接杀掉了事，要深挖原因：
- 查该进程的内存映射：cat /proc/PID/smaps | awk ‘/^Size:/ {sum+=$2} END {print sum}’，再对比 /proc/PID/status 中的 VmRSS，差值大说明存在大量未映射但已分配的虚拟内存（如 Java 堆外内存、mmap 大块未用区域）
- 看是否频繁 minor/major fault：watch -n1 ‘cat /proc/PID/status | grep -E “(VmRSS|MMU|thr)”‘，配合 perf record -e page-faults,minor-faults,major-faults -p PID 观察缺页行为
- 对 Java 应用：加 -XX:+PrintGCDetails -Xloggc:gc.log，并用 gceasy.io 分析 GC 日志；检查是否存在 DirectByteBuffer 泄漏、静态集合无清理、线程数失控
临时缓解与长期治理
OOM 不是故障终点，而是系统设计信号：
- 紧急止血：echo -17 > /proc/PID/oom_score_adj 可降低关键进程被杀优先级（仅临时，重启失效）；swapoff && swapon 可重置 swap 状态（慎用）
- 限制资源边界：用 systemd 设置 MemoryMax=2G、MemoryHigh=1.5G，或 cgroup v2 统一管控；容器场景务必设–memory 和–memory-swap
- 监控前置化：部署 node_exporter + Prometheus，告警指标包括 node_memory_CommitLimit_bytes – node_memory_Committed_AS_bytes gout 陡升、slab_unreclaimable > 500MB
