MySQL OOM 系列一 Linux記憶體分配_MySQL

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的機制。