Linux OOM Killer 机制与 MySQL 内存超售策略解析

Hazel

发布时间：2026-10-13| 4人浏览过

原创

MySQL 等应用在 Linux 环境下可能因内存超售（OverCommit）策略触发 OOM 异常。本文详解 Linux 内存分配机制、overcommit_memory 配置参数含义及验证方法，帮助理解系统如何平衡资源利用率与稳定性。

Linux 内存超售机制 (OverCommit)

在开发 C/C++ 程序时，通常习惯使用 malloc 动态申请内存空间。按照一般思维，malloc 会向操作系统申请一段连续的内存单元并返回起始地址；若返回 null，则代表系统无可用内存。这在 Solaris 等部分系统中是标准行为。

然而，Linux 采用了更积极的分配策略。系统假设应用申请内存后不会立即使用，因此允许一定程度的"超售"。当应用真正需要内存时，操作系统可通过回收其他应用已释放的内存来满足需求。简言之，Linux 允许应用申请的虚拟内存总量超过物理内存加 Swap 的大小，这一特性称为 OverCommit。

第一步：查看并理解 overcommit_memory 配置参数

目的：了解当前系统允许的内存超售程度，判断是否存在风险。 入口：终端命令行 动作：读取 /proc/sys/vm/overcommit_memory 文件内容。 参数说明：
该参数控制 Linux 内核的内存分配行为，支持以下三种模式：
1. 0（默认值）：由内核通过启发式算法决定。通常允许轻微超售，拒绝明显不可能的请求，并对不同用户限制超售比例。
2. 1（总是超售）：允许不做限制的超售。上限受寻址空间限制（32位约4G，64位约16T），即使物理内存不足也会成功分配指针，直到实际写入数据时失败。
3. 2（禁止超售）：严格禁止超售。系统可分配的内存不超过 Swap + 物理内存 * overcommit_ratio。其中 overcommit_ratio 默认为 50%，可通过修改 /proc/sys/vm/overcommit_ratio 调整。

第二步：验证内存分配策略的差异

为直观展示上述策略的影响，我们可以通过两段简单的 C 语言代码进行对比测试。核心区别在于申请内存后是否立即写入数据（即"预分配"与"延迟分配"）。

#include <stdio.h>
#include <stdlib.h>
#define MEGABYTE 1024*1024
int main(int argc, char *argv[])
{
    void *myblock = NULL;
    int count = 0;
    // 模式A：仅申请内存，不立即使用
    while (1)
    {
        myblock = (void *) malloc(MEGABYTE);
        if (!myblock) break;
        printf("Currently allocating %d MB\n", ++count);
    }
    exit(0);
}

#include <stdio.h>
#include <stdlib.h>
#define MEGABYTE 1024*1024
int main(int argc, char *argv[])
{
    void *myblock = NULL;
    int count = 0;
    // 模式B：申请后立即填充数据
    while(1)
    {
        myblock = (void *) malloc(MEGABYTE);
        if (!myblock) break;
        memset(myblock, 1, MEGABYTE); // 强制触发物理页分配
        printf("Currently allocating %d MB\n", ++count);
    }
    exit(0);
}

在 1G RAM 和 400M Swap 的虚拟机环境下运行结果如下：

结果分析：
- 模式A（未使用）：进程可以申请远超实际物理+Swap 总和的内存空间。这是因为 malloc 只分配了虚拟地址空间，尚未触发生效的物理页面分配，Linux 内核通过 OverCommit 机制予以放行。
- 模式B（立即使用）：由于每次申请后都执行 memset 写入数据，强制系统为其分配真实的物理内存页。一旦耗尽所有可用物理内存和 Swap，malloc 将返回 null，进程停止增长。