最直接判断系统是否被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。
