4. Overcommit 策略详解：vm.overcommit_memory=0/1/2 的区别、vm.overcommit_ratio 与 vm.overcommit_kbytes 的作用

Overcommit（内存超额分配）是 Linux 内核内存管理中最具争议也最关键的策略之一。它决定了内核在响应 malloc() 或 mmap() 等内存分配请求时，是否允许分配超出物理内存 + 交换空间总量的虚拟内存。理解 vm.overcommit_memory 的三个模式以及配套的 vm.overcommit_ratio / vm.overcommit_kbytes 参数，是精准控制 OOM Killer 触发边界、实现安全内存超卖的前提。

核心认知： Overcommit 策略直接决定了系统“承诺”给进程的内存上限。策略越宽松，内存利用率越高，但 OOM 风险也越大；策略越保守，系统越稳定，但内存浪费也越明显。

4.1 三种 Overcommit 模式：0 / 1 / 2

内核通过 /proc/sys/vm/overcommit_memory 文件控制 Overcommit 策略，支持三种模式。以下表格从分配规则、适用场景和风险三个维度进行对比：

模式值 模式名称 分配规则 典型场景 OOM 风险
0 启发式（Heuristic） 内核根据当前内存压力、进程行为等启发式判断是否允许分配；允许适度超卖 通用桌面/服务器默认值 中等
1 始终允许（Always） 只要虚拟地址空间未耗尽，malloc() 几乎总是成功；允许大量超卖 内存超卖型容器、数据库缓存池 高
2 严格禁止（Strict） 分配总量不得超过 CommitLimit（由 ratio/kbytes 计算得出），否则返回 ENOMEM 金融交易系统、实时系统、关键数据库 低
生产建议： 绝大多数生产环境应使用 模式 2（严格模式），配合合理的 overcommit_ratio 值，既能控制 OOM 风险，又能保留一定的超卖弹性。模式 0 的启发式算法在内存压力大时行为不可预测，模式 1 则几乎完全放弃保护。

以下 SVG 图展示了三种模式在内存分配请求时的决策路径差异：

三种 Overcommit 模式决策流程对比 进程发起 malloc() 模式 0：启发式判断 内核评估内存压力、 进程行为、剩余空间 允许 / 拒绝（模糊） 模式 1：始终允许 仅检查虚拟地址空间 是否耗尽 几乎总是成功 模式 2：严格限制 计算 CommitLimit 检查已分配总量 超过则返回 ENOMEM CommitLimit = 物理内存 × overcommit_ratio% + swap （模式 2 下，分配总量超过此值即拒绝）

4.2 模式 2 的核心：CommitLimit 计算

当 overcommit_memory = 2 时，内核使用以下公式计算系统允许的最大已承诺内存总量（CommitLimit）：

CommitLimit = (物理内存总量 × vm.overcommit_ratio / 100) + 交换空间总量

如果 vm.overcommit_kbytes 被设置为非零值，则上述公式中的 物理内存总量 × vm.overcommit_ratio / 100 部分被 vm.overcommit_kbytes 直接替换：

CommitLimit = vm.overcommit_kbytes + 交换空间总量
关键理解： CommitLimit 不是物理内存上限，而是“承诺内存”上限。进程申请了但尚未实际使用的虚拟页（如 malloc() 后未写入的页面）会计入承诺内存，但不占用物理页框。这就是超卖能够工作的根本原因。

4.3 vm.overcommit_ratio 与 vm.overcommit_kbytes 的作用

这两个参数仅在 overcommit_memory = 2 时生效，用于精确控制 CommitLimit 的计算基数：

参数 单位 默认值 作用 典型调优范围
vm.overcommit_ratio 百分比（%） 50 物理内存中可用于承诺内存的比例基数 50 ~ 100（物理内存充裕时可提高）
vm.overcommit_kbytes KB 0（禁用） 直接指定物理内存中可用于承诺内存的绝对值，覆盖 ratio 计算 根据实际物理内存大小设定

以下 SVG 图展示了 ratio 与 kbytes 在 CommitLimit 计算中的协作关系：

vm.overcommit_ratio 与 vm.overcommit_kbytes 计算逻辑 物理内存总量 vm.overcommit_ratio vm.overcommit_kbytes kbytes 是否为 0？ CommitLimit = kbytes + swap CommitLimit = 内存×ratio% + swap 注意：overcommit_kbytes 优先级高于 overcommit_ratio 设置 kbytes 后，ratio 参数被忽略

4.4 实战调优：如何设置 Overcommit 参数

以下步骤演示了在 64GB 物理内存、8GB Swap 的服务器上，如何配置一个安全且允许适度超卖的 Overcommit 策略：

  1. 确认当前策略： 
    cat /proc/sys/vm/overcommit_memory
# 输出 0 表示默认启发式模式
  2. 切换为严格模式： 
    echo 2 > /proc/sys/vm/overcommit_memory
# 或永久生效：在 /etc/sysctl.conf 中添加
# vm.overcommit_memory = 2
  3. 计算并设置 ratio： 
    # 目标：允许承诺内存 = 物理内存的 80% + 8GB Swap
# CommitLimit = 64GB × 80% + 8GB = 59.2GB
echo 80 > /proc/sys/vm/overcommit_ratio
  4. 验证 CommitLimit： 
    grep -E 'CommitLimit|Committed_AS' /proc/meminfo
# CommitLimit:   60620800 kB  (约 59.2GB)
# Committed_AS:  32000000 kB  (当前已承诺内存)
  5. 监控承诺内存水位： 
    # 当 Committed_AS 接近 CommitLimit 时，新分配将返回 ENOMEM
# 建议设置告警阈值：Committed_AS / CommitLimit > 0.85
调优黄金法则： 对于数据库类应用（如 MySQL、PostgreSQL），建议 overcommit_ratio 设置在 70~90 之间，保留 10%~30% 的物理内存作为“安全余量”给内核和紧急分配。对于容器化平台（如 Kubernetes），可适当提高至 100 甚至 120（配合 Swap），但必须配套严格的 Cgroup 内存限制。

4.5 三种模式的实时监控与诊断

无论使用哪种模式，以下指标都是诊断 Overcommit 状态的关键：

指标 来源 说明 告警阈值建议
CommitLimit /proc/meminfo 系统允许的最大承诺内存总量（仅模式 2 有意义） —
Committed_AS /proc/meminfo 当前所有进程已承诺的虚拟内存总量 超过 CommitLimit 的 85%
MemAvailable /proc/meminfo 在不触发 Swap 的情况下，新进程可用的物理内存估算值 低于总内存的 10%
OOM 触发计数 /proc/vmstat | grep oom 系统自启动以来 OOM Killer 被触发的次数 大于 0 即需关注
模式 0 的陷阱： 在模式 0 下，/proc/meminfo 中的 CommitLimit 字段显示的值是 物理内存 + Swap（即理论最大值），但实际分配行为由内核启发式算法动态决定，因此 CommitLimit 在模式 0 下不具备严格的限制意义，容易给管理员造成误导。建议生产环境统一使用模式 2。

以下 SVG 图展示了从 Overcommit 策略配置到 OOM Killer 触发的完整链路：

Overcommit 策略 → OOM Killer 触发链路 配置 overcommit_memory 设置 ratio / kbytes 计算 CommitLimit 进程 malloc() 请求 超过 CommitLimit？ 分配成功（正常） 返回 ENOMEM 物理内存 + Swap 耗尽 触发 OOM Killer 选择进程并杀死

4.6 常见误区与避坑指南

  • 误区一：模式 2 下设置 ratio=100 就绝对不会 OOM
    错误。即使 CommitLimit 足够大，如果物理内存 + Swap 被实际写满（Committed_AS 对应的物理页框占满），内核仍会触发 OOM Killer。模式 2 只控制“承诺”上限，不控制“实际使用”上限。
  • 误区二：overcommit_kbytes 比 ratio 更精确
    不一定。kbytes 适合固定内存大小的环境（如嵌入式、容器），ratio 则更适合物理内存可动态变化的场景（如热插拔内存、虚拟机动态调整）。
  • 误区三：模式 0 比模式 2 更“智能”
    模式 0 的启发式算法在内核社区长期被诟病为“黑盒”，在内存压力下可能做出错误决策。模式 2 配合合理的 ratio 才是可预测、可运维的方案。
  • 误区四：Swap 空间越大，Overcommit 越安全
    过度依赖 Swap 会导致性能急剧下降（磁盘 I/O 瓶颈），且 Swap 本身也会被计入 CommitLimit。建议 Swap 大小不超过物理内存的 50%。
本章小结： Overcommit 策略是 OOM Killer 的第一道防线。模式 2（严格模式）配合 overcommit_ratio（推荐 70~90）是最适合生产环境的组合。理解 CommitLimit 的计算方式，并持续监控 Committed_AS 与 CommitLimit 的比例，是预防 OOM 的关键手段。下一章将深入探讨 OOM Killer 的核心算法——badness 评分机制，揭示内核如何选择“牺牲品”。
← 上一章 📖 返回目录 下一章 →