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
