LinuxOOM问题排查流程_内存不足场景分析【教程】

最直接判断系统是否被 OOM Killer 干掉是检查 dmesg 日志中是否有“Out of memory: Kill process”记录，需结合时间戳与业务异常时刻比对，并注意 oom_score_adj、RSS 及运行时长等被杀依据。

怎么看系统是不是被 OOM Killer 干掉了

最直接的判断方式是检查内核日志里有没有 Out of memory: Kill process 这类记录。OOM Killer 触发后，dmesg 输出里通常紧跟着进程名、PID、内存占用 估算值和被选中的理由。

执行：

dmesg -T | grep -i "killed process"

或更宽泛地：

dmesg -T | grep -E "(Out of memory|Killed process)"

• 注意时间戳是否贴近业务异常发生时刻
• 被杀进程不一定就是罪魁祸首，oom_score_adj 值高、RSS 大、运行时间短的进程更容易被挑中
• 如果日志里只有 page allocation failure 但没看到 Killed process，说明还没走到 OOM Killer 阶段，可能是内存碎片或直接回收失败

/proc/sys/vm/overcommit_memory 设为 1 真的能防 OOM 吗

不能，它只是改变内存申请时的检查策略，不是内存不足的解药。设为 1 表示“总是允许分配”，内核不再校验是否有足够空闲页，等真正写入时才可能触发 OOM —— 实际上让问题延后、更难定位。

常见误判场景：

echo 1 > /proc/sys/vm/overcommit_memory

后应用看似启动更快，但运行几小时后突然被杀，且 dmesg 显示大量匿名页分配失败。

• overcommit_memory=0（默认）：启发式检查，较保守
• overcommit_memory=2：严格模式，CommitLimit = SwapTotal + vm.overcommit_ratio * RAM，适合对稳定性要求高的服务
• 改完记得同步更新 /etc/sysctl.conf，否则重启失效

top 或 ps 看 RSS 高就一定是内存泄漏吗

不一定。RSS（Resident Set Size）反映的是进程当前实际占用的物理内存页，但它包含共享库、mmap 映射、tmpfs 文件等非堆内存区域。Java 应用常因 DirectByteBuffer 或 JNI 调用导致 RSS 持续上涨，而堆内存（jstat -gc）却很平稳。

排查建议：

• 用 pmap -x 查看各内存段分布，重点关注 anon 和 mapped 区域大小
• 对 Java 进程，加 JVM 参数 -XX:NativeMemoryTracking=detail 后用 jcmd VM.native_memory summary 对比
• 检查是否启用了 transparent_hugepage，某些版本内核下它会导致 RSS 虚高且难以释放

为什么 free -h 显示还有几 G 空闲，系统却触发 OOM

因为 free 显示的“available”才是真正可立即分配的内存；“free”字段只是完全未使用的页，现代 Linux 会把空闲内存用于 page cache、slab 等缓存，这些在需要时本该快速回收 —— 但如果回收速度赶不上分配速度（比如突发大量 mmap(MAP_ANONYMOUS)），就会 OOM。

关键指标要看：

cat /proc/meminfo | grep -E "(MemAvailable|MemFree|Buffers|Cached|SReclaimable|PageTables|CommitLimit|Committed_AS)"

• MemAvailable 显著低于 MemTotal * 0.1 是危险信号
• Committed_AS > CommitLimit 表示已超承诺上限，即使 MemAvailable 还有余量，OOM Killer 也可能随时介入
• 某些容器环境（如 cgroups v1）中，MemAvailable 不反映 cgroup 限额，得看 /sys/fs/cgroup/memory/xxx/memory.usage_in_bytes

OOM 的根本难点不在识别，而在区分「谁在持续吃内存」和「谁只是恰好站得太高」——oom_score 是结果，不是原因。查到被杀进程后，务必回溯它的内存增长路径，而不是只调大 oom_score_adj 或加 swap。