MySQL OOM 系列一 Linux内存分配

rds（网易云关系数据库服务）上线已经有一段时间，陆续不断有产品迁入到了rds中，在线上运维的过程中，也遇到了一些曾经没有考虑到，或者考虑的不全的东西。后续有时间可以分享给大家。

今天想提到的是线上一个4g的rds实例，发生了oom（out of memory）的问题，mysql进程被直接kill掉了。在解释这个问题的时候，我们首先需要从linux系统内存分配策略讲起。
    一般写c语言程序，我们习惯使用malloc动态的申请内存空间（java由jvm负责内存管理），malloc函数会向操作系统申请一段连续的内存单元，然后返回这段空间的起始地址。如果malloc函数返回为null则表示系统没有可分配的内存空间。这是我们的一般思维，当然这在某些操作系统中确实也是正确的（solaris）。
     但是linux不是这样的，linux的内存分配采取的是一种更加积极的分配策略，它假设应用申请了内存空间后并不会立即去使用它，所以允许一定量的超售，当应用真的需要使用它的时候，操作系统可能已经通过回收了其他应用的内存空间而变得有能力去满足这个应用的需求，简单的说，就是允许应用申请比实际可分配空间（包括物理内存和swap）更多的内存，这个特性称为overcommit。
      这个特性在linux操作系统里面也是可配的，可以通过设置/proc/sys/overcommit_memory为不同的值来调整overcommit策略。
     overcommit_memory可以取3个值：
0：默认值，由linux内核通过一些启发式算法来决定是否超售和超售的大小，一般允许轻微的超售，拒绝一些明显不可能提供的请求，同时做一些规则限制，比如不同用户overcommit的大小也不一样。
1：允许，不做限制的超售，当然这个也不是无限大，还受到寻址空间的限制，32位系统最大可能只有4g，64位系统大概16t左右。
2：禁止，禁止超售，系统能够分配的内存不会超过swap+实际物理内存*overcommit_ratio，该值可以通过/proc/sys/vm/overcommit_ratio设置，默认50%。

    为了验证linux的内存分配，我们用个小程序来测试一下：

#include <stdio.h>
#include <stdlib.h>
#define megabyte 1024*1024
int main(int argc, char *argv[])
{
    void *myblock = null;
    int count = 0;

    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;

    while(1)
    {
        myblock = (void *) malloc(megabyte);
        if (!myblock) break;
        memset(myblock,1, megabyte);
        printf("currently allocating %d mb\n",++count);
    }
    exit(0);
    
}

前者再通过malloc()申请了内存空间以后，并没有立即去使用它，而后者相反，每次申请完都立即用1去填充。我们来看看两个程序运行的结果。

这是在1g的ram，400m swap的虚拟机上运行的结果，前者申请了远远超过实际内存的空间，后者并没有超过实际内存可用空间。这就验证了前面叙述的linux的内存分配策略。
本身这是一个系统的优化，无可厚非。但是我们知道，但凡“超售”都是基于不会有大量程序同时使用资源的假设，这显然也是有风险的。所以linux又使用了一种oom killer(out of memory killer)的机制，在系统可用内存（包括swap）即将使用完之前，选择性的kill掉一些进程以求释放一些内存。下一章我们重点讨论一下linux oom killer的机制。