linux oom频繁触发主因是内核判定“无安全可用内存”，非真耗尽：跌破vm.min_free_kbytes水位且无法快速回收连续页即触发；需据日志三要素锁定真凶，区分全局或cgroup级超限，并通过调参、加swap、earlyoom等预防。
Linux OOM 频繁触发，往往不是内存“真用光了”，而是内核判定“已无安全可用内存”——哪怕 free -h 显示还有几百 MB，只要跌破 vm.min_free_kbytes 这条硬水位线，又无法快速回收足够连续页，OOM Killer 就会出手。关键在于识别日志特征、定位真实瓶颈，并做有针对性的规避。
看懂 OOM 日志：三步锁定“真凶”
别只扫一眼 dmesg | grep "Out of memory"。真正可靠的证据必须包含以下三要素：
-
明确出现
Killed process字样，后跟具体 PID 和进程名（如Killed process 2841 (java)） -
列出内存快照数据：
total-vm（虚拟内存）、anon-rss（实际占用物理内存）、file-rss（文件映射内存） -
匹配
/var/log/messages或journalctl -k中同一时间点的完整上下文，确认是否为全局 OOM 还是 cgroup 级别
若只看到 Out of memory: Kill process 却没列 PID，说明当时系统已极度紧张，连日志缓冲区都快溢出，需立即检查 vm.panic_on_oom 是否为 1（会直接重启）。
区分两类根本原因：全局 vs cgroup
频繁 OOM 不等于整机内存不够，要先分清是哪一层在告急：
-
全局内存不足：查看
free -h的available值持续接近 0，Cached很高但释放滞后；vmstat 1中si/so（swap in/out）持续非零，说明 swap 正在被高频使用 -
cgroup 内存超限：日志中明确出现路径如
cgroup: /system.slice/docker-abc123.scope或/mm_test；用cat /sys/fs/cgroup/memory/xxx/memory.usage_in_bytes对比memory.limit_in_bytes即可确认是否触顶
容器或 systemd service 场景下，cgroup 限制常被忽略——一个 Java 应用设了 -Xmx4g，但所在 cgroup 只给了 3g，必然触发内部 OOM，和宿主机总内存无关。
有效规避策略：从临时止血到长期稳定
避免“一杀了之”，重点放在预防和隔离：
-
给关键进程加“免死金牌”：运行中修改
/proc/<pid>/oom_score_adj</pid>，设为-1000（最低值），公式为(RSS / limit) × 1000 + oom_score_adj，负值直接压低“badness 分数” -
调低
vm.min_free_kbytes：64 位系统建议设为总内存的 0.5%~1%，例如 32G 内存可设524288（512MB）；过高（如误设 1GB+）会导致过早触发 -
必配 swap：阿里云等云主机默认无 swap，执行
dd if=/dev/zero of=/swapfile bs=1G count=4 && mkswap /swapfile && swapon /swapfile，虽有性能折损，但能极大延缓 OOM 触发时机 - 用 earlyoom 替代被动等待：它在内核 OOM 触发前就介入，基于内存趋势主动 kill，响应更及时，配置也更灵活
排查泄漏与配置陷阱
很多“频繁 OOM”实为缓慢积累所致：
- 查
ps aux --sort=-%mem | head -10，重点关注RES持续增长、且不随业务低峰回落的进程 - Java 应用务必核对
-Xmx总和是否超过物理内存减去系统保留量；JVM Native Memory（如 Direct Buffer、Metaspace）不计入堆，但同样吃物理内存 - 检查
/proc/sys/vm/swappiness是否合理（推荐 10~30），过高会导致 cache 过早换出，加剧抖动
不复杂但容易忽略。
