引言：内存超额承诺与OOM Killer的关系
验证与回滚
说到Linux OOM，很多问题都出在细节上。运行在Linux上的Java应用、数据库或Web服务器，偶尔会在毫无征兆的情况下被内核杀死。系统日志中往往能看到类似“Out of memory: Killed process xxx”的记录。这种“被Kill”的背后，是内核的OOM Killer（Out-Of-Memory Killer）机制在发挥作用。理解它的触发原理和关联的vm.overcommit_memory参数，对于保障生产环境稳定性至关重要。
大多数Linux发行版默认允许内存过量分配（overcommit），即进程申请的内存可以超过物理内存+交换空间的总和。内核假设并非所有进程都会同时使用其申请的每一字节。但当实际内存耗尽且无法通过回收页面或交换满足需求时，内核必须选择一个进程杀掉以释放内存，这个最终手段就是OOM Killer。
相关阅读：此处可内链到“Linux OOM常见问题”专题。
OOM Killer 触发原理
内存分配路径与oom触发点
进程通过系统调用（如brk、mmap）申请内存时，内核的page fault处理函数负责真正分配物理页面。分配路径根据可用页面多少分为三个水位：
- pages_min：绝对保留的最低页数，通常用于原子分配。一旦空闲低于此值，分配优先级最高的进程也可能触发OOM。
- pages_low：低于此水位后，内核在分配前会尝试回收页面，但仍允许部分分配，不会直接触发OOM。
- pages_high：高于此水位时，分配无需回收，属于“富足”状态。
当空闲页面低于pages_low且回收页面的努力（kswapd）仍无法满足分配请求时，内核会调用__alloc_pages_slowpath。在该函数中，若多次尝试均失败，最终进入out_of_memory()函数，触发OOM Killer。
选择“处刑”进程的算法
内核会为每个进程计算一个oom_score，得分最高的进程被杀。分数计算依据包括：
- 进程占用的物理内存大小（RSS）。占用越大越可能被选中。
- 进程的oom_adj或oom_score_adj值（可通过cgroup或proc调整）。默认值为0，取值范围-1000到+1000。正值增加被杀概率，负值降低。设为-17或-1000可使进程彻底豁免。
- 子进程数量、是否为root启动、是否占用交换空间等。
内核会先选出候选进程集（除init、kthread及设置了OOM_SCORE_ADJ_MIN的进程），然后在筛选出的进程中按分数排序。若多个进程分数相同，则选择最先遍历到的那个。这种“最小代价”原则虽然保证了系统能快速恢复，但可能误杀关键服务。
补充参考：此处可内链到“Linux OOM故障排查实例”。
vm.overcommit_memory 参数详解与Linux OOM
vm.overcommit_memory是控制内核对内存过量分配行为的关键参数，位于/proc/sys/vm/overcommit_memory。它有三个可能的值：
0 —— 启发式过度分配（默认）
内核试图对内存请求的合理性做出判断。对于明确映射到后备文件的内存（如mmap文件），内核允许超额；对于匿名映射（如malloc），内核会检查是否超过系统总物理内存+交换空间的某个比例。判断存在误差，但大多数情况下能有效避免OOM触发的同时正常运行多数进程。默认比例由overcommit_ratio（通常为50）间接确定。此模式下系统仍可能因突发大内存申请触发OOM。
1 —— 总是允许超额分配
内核忽略所有内存分配的大小限制，永远不拒绝malloc等调用。只要有虚拟地址空间，申请就会成功。进程可以在物理内存耗尽前继续分配虚拟内存，但实际使用时会因缺页分配物理内存而失败，导致段错误（SIGSEGV）或被OOM Killer杀掉。此模式适用于内存消耗不可预测但响应速度要求极高的场景（如某些科学计算）。代价是系统可能在无预警情况下崩溃。
2 —— 禁止超额分配（严格模式）
内核承诺不会分配超过“可承诺内存量”的虚拟内存。可承诺内存量的计算公式为：
CommitLimit = (swap + RAM * overcommit_ratio / 100)
默认overcommit_ratio为50（某些发行版可能不同）。当总虚拟内存申请超过CommitLimit时，系统调用返回错误（如ENOMEM）。此模式下OOM Killer几乎不会被触发，因为进程在申请阶段就被拒绝了。副作用是某些依赖于大量虚拟内存但实际物理占用很少的应用程序（如稀疏数组、fork后立即exec的守护进程）可能无法正常启动，需要提高overcommit_ratio或禁用严格模式。
同时，vm.overcommit_kbytes（自Linux 2.6.29引入）可覆盖overcommit_ratio的百分比计算，直接指定一个绝对字节数作为可承诺上限，单位KB。大多数场景保持默认即可。
延伸阅读：此处可内链到“Linux OOM配置案例”相关文章。
调优策略与实践——Linux OOM
何时需要调整vm.overcommit_memory
如果你的应用稳定运行且偶尔出现OOM Killer，先排查内存泄漏或突发尖峰。若确认是正常的内存请求组合导致内核误判，考虑：
- 业务对服务连续性要求高，不允许被内核随机杀进程：使用
vm.overcommit_memory=2并调大overcommit_ratio，确保所有进程的物理内存实际需求总和不超过CommitLimit。 - 应用启动时会大量申请虚拟内存（如Java JVM的初始堆、C++ std::vector预分配），但实际使用缓慢增长：保持默认为0或1，同时将关键进程的
/proc/self/oom_adj设为-17以防止被选中。
避免OOM Killer的有效措施
- 限制单一进程内存：使用cgroup memory限制或ulimit -v降低每个进程的虚拟内存上限。但注意ulimit只影响虚拟地址空间，不限制物理页使用。
- 合理配置交换分区：增大swap空间可以让内核在物理内存紧张时将不活跃页面换出，降低OOM概率。但swap性能远低于RAM，需权衡。
- 监控与预警：对内存使用率设置阈值报警，当
/proc/meminfo中Committed_AS接近CommitLimit时提前响应。 - 调整overcommit_ratio：若采用模式2，计算物理内存+swap的安全比例。假设物理内存64GB，swap16GB，应用最大RSS为48GB，则可将overcommit_ratio设为75（即64*0.75=48），加上swap16G得到CommitLimit=64GB，留出空间给系统开销。
验证与回滚
任何内核参数修改前务必在测试环境验证。命令sysctl -w vm.overcommit_memory=2立即生效，但重启后失效。若要持久化，写入/etc/sysctl.conf。若变更导致应用无法启动，立即执行sysctl -w vm.overcommit_memory=0恢复默认。建议在变化较大的业务服务器上先执行：
echo 2 > /proc/sys/vm/overcommit_memory
并监控/proc/meminfo的CommitLimit和Committed_AS，确认无异常后再写入配置文件。
总结
验证与回滚
OOM Killer是内核的最后保护机制，其触发与vm.overcommit_memory密切相关。透彻理解水位算法、进程选择逻辑和三个overcommit模式，能够帮助运维人员根据业务特性做出明智选择：是宽松接受超额分配换来更大并发，还是严格限制换取消杀风险。没有银弹，每一次调优都需要结合实际内存占用量、应用分配模式和故障容忍度进行权衡。后续只要定期检查关键指标，Linux OOM就不会变成维护负担。
延伸阅读