[[392359]]

先來看段代碼：

 

這段代碼非常簡單，就是先用mmap的方式，為該進程分配10GiB的虛擬內存，然后再用page寫的方式，讓操作系統為這10GiB虛擬內存，分配對應的物理內存，最后sleep，等待我們測試。

運行下：

 

沒啥問題，和我們預期的一樣，正常執行。

打開另一個終端，執行以下命令，看下它的內存占用：

 

上圖中的VSZ指的是虛擬內存，RSS指的是物理內存，單位都是KiB，所以該進程虛擬內存和物理內存的使用，都約等于10GiB，沒問題。

我們再開個終端，再執行下這個程序：

 

第二次執行這個程序也沒問題，但奇怪的是，此時第一次執行的那個程序卻被kill掉了：

 

這是為什么呢?

上面我們說到，該程序的邏輯是分配10GiB的物理內存，所以運行兩次，也就是要分配20GiB的物理內存。

但在我們的測試機器上，物理內存一共才16GiB，所以，運行兩個這樣的進程肯定是不行的。

在第二次執行該程序，且向操作系統申請物理內存時，操作系統會發現，物理內存已經沒有了。

此時，為了防止整個系統crash掉，linux內核會觸發 OOM/Out of Memory killing 機制，即按照一定的規則選擇一個進程，將其kill掉，以便回收物理內存，以此來保證機器整體的穩定運行。

同時，該kill事件，也會被記錄到內核日志中，且可通過dmesg命令等方式查看。

比如上面第一個進程被kill掉的事件記錄如下：

 

看上面紅色字體行，該行是說，進程14134因為out of memory被linux內核kill掉了，該進程正是上面我們第一次執行的那個程序。

linux內核的oom killing機制，其實是一種棄車保帥的做法，因為如果我們不kill掉某進程，來釋放物理內存的話，那很有可能會導致后續系統級別的crash，兩害相權取其輕，操作系統只能這樣處理，歸根結底，是我們對進程使用物理內存的規劃不足，才導致了這種情況。

那為什么不在第二次執行該程序時，在調用mmap分配虛擬內存時就直接報錯，返回無法分配內存呢?

這是因為，經過多年觀察，linux內核的開發人員發現，絕大部分程序在分配了很大的虛擬內存之后，在大部分時間里，并不會一直使用這么多的物理內存。

所以，為了更合理更高效的利用物理內存資源，linux內核允許虛擬內存的overcommit，即，例如在上面執行mmap分配虛擬內存時，linux內核并不會嚴格檢查，所有運行中的進程分配的虛擬內存加起來，是否超過了整個物理內存大小。

這也就解釋了為什么上面第二次運行該程序時，mmap是沒有報錯的。

但是，雖然mmap的虛擬內存分配成功了，但當真正使用該內存時，比如上面的寫內存，此時要分配物理內存，則是有可能失敗的，因為虛擬內存的overcommit，很可能導致后續的物理內存不足。

如果真的發生了這種情況，就會觸發linux內核的oom killing機制，即linux內核中的oom killer會按一定的規則，選一個進程，將其kill掉，這個上面我們已經演示過了。

那為什么不kill掉第二個進程，而是kill掉第一個呢?

這個和linux內核中oom killer的選擇策略有關，我們直接看源碼：

 

當進程請求操作系統為其分配物理內存時，如果此時物理內存已經沒有了，則會觸發上圖中的out_of_memory函數。

該函數中，會使用select_bad_process選擇要被kill掉的進程，然后使用oom_kill_process將其kill掉，來釋放物理內存。

在看select_bad_process之前，我們先看下oom_kill_process：

 

該函數調用了__oom_kill_process：

 

在上面的函數中，通過向victim進程發送SIGKILL這個signal(我們平時使用的kill -9命令，就是用的這個signal)，將其kill掉，然后該kill事件，會被記錄到內核日志中。

注意，這里記錄的日志格式，正好和我們上面用dmesg輸出的，14134進程被kill掉事件日志格式完全一樣。

kill掉進程的過程就是這樣，我們再來看下select_bad_process函數是如何選擇要被kill掉進程的：

 

在該函數中，會遍歷系統中的所有進程，然后使用oom_evaluate_task這個函數，對各個進程進行評估：

 

oom_evaluate_task函數中，會使用oom_badness，計算某進程badness的點數，點數越高，越容易被kill掉。

如果badness的點數是LONG_MIN這個特殊值，則直接跳過該進程，即該進程不會成為被kill掉的對象，如果badness點數小于之前選擇進程的badness點數，同樣也跳過該進程，即被kill掉的進程badness點數要是最大的。

遍歷中選擇的進程，及其badness的點數，會被賦值到oc->chosen和oc->chosen_points里，oc->chosen最終指向的進程，就是上面oom_kill_process里kill掉的進程。

我們再來看下badness點數是如何計算的：

 

該函數主體邏輯分成兩部分，一部分是，在某些情況下，該進程的badness點數直接返回LONG_MIN，即不會被kill掉。

這些情況包括，oom_score_adj的值為OOM_SCORE_ADJ_MIN，即-1000，或者該進程已經在被kill的過程中了，或者該進程在vfork過程中。

該函數邏輯的另外一部分就是計算進程的badness點數，其大致計算規則為：

points = 該進程占用的物理內存總數 + 總物理內存 * oom_score_adj值的千分比。

oom_score_adj的值，是進程獨有的，是可以通過寫 /proc/[pid]/oom_score_adj 的方式調整的，取值范圍為 -1000 到 1000。

該值越大，進程總的badness點數就會越大，進程也就越容易被kill掉。

該值越小，進程總的badness點數就會越小，該進程也就越不容易被kill掉。

上面我們還提到oom_score_adj有一個特殊值為OOM_SCORE_ADJ_MIN，即-1000，表示該進程不能被kill掉。

各進程的oom_score_adj的值默認為0。

綜上可知，linux內核中oom killer選擇被kill進程的方式，就是看各進程badness點數的大小。

默認情況下，因為各進程的oom_score_adj的值都為0，所以進程占用的物理內存越大，其badness點數也就越大，其也就越容易被kill掉。

這也就解釋了，為什么上面在第二次執行那個程序時，被kill掉的是第一次執行的那個進程，而不是第二次執行的進程，因為第一次執行的那個進程，占用的物理內存更大。

其實，調整linux內核中oom killer行為的方式有很多，不止修改oom_score_adj值這一種方法。

比如，通過修改 /proc/sys/vm/panic_on_oom 的值，可以讓整個系統在物理內存不夠時，直接panic，而不是選擇性的kill掉某個進程。

比如，通過修改 /proc/sys/vm/overcommit_memory 的值，可以使上面第二次執行的測試程序，在使用mmap分配虛擬內存時，就直接報錯，說內存不夠。

比如，通過修改 /proc/[pid]/oom_adj 值的方式，同樣可以達到修改 /proc/[pid]/oom_score_adj 的目的，不過這個在內核2.6.36版本之后已經不推薦使用。

oom killer行為調整的相關參數，其具體詳解可以看proc的man文檔：

https://man.archlinux.org/man/proc.5

聊了這么多，那理解linux內核的oom killer機制，對于我們實際應用有哪些幫助呢?

我們假設以下場景：

假如，我們有一臺機器，上面跑著一個非常重要的服務，比如數據庫，或者某個應用進程等。

它非常耗內存，但是正常情況下，它使用的物理內存肯定不會高于實際總物理內存大小。

有一天我們需要在這臺機器上執行一項任務，如果這個任務也比較耗內存，那很可能在執行這項任務時，整臺機器的物理內存就完全不夠用了，此時，就會觸發linux內核的oom killing機制。

又因為在不調整oom_score_adj值的情況下，linux內核中的oom killer默認kill掉的，就是占用物理內存最多的那個進程，一般來說，就是我們數據庫進程，或其他應用進程，假設這個進程又是線上的一個重要服務，那它被kill掉了，你想一下這會是多么嚴重的一個事故。

那怎么避免呢?

此時，我們就可以使用上面提到的，用于調整進程badness點數的，oom_score_adj 這個參數。

比如，我們可以通過 echo -1000 > /proc/[pid]/oom_score_adj 命令，將oom_score_adj的值設置為-1000，即該進程不能被kill掉。

又比如，還是通過上面的echo命令，將oom_score_adj的值修改為一個較小的值，來降低它被kill掉的概率。

但是，這些方法其實都不是完美的解決方式。

雖然該機器上的這個重要服務不被kill掉了，但操作系統為了保證整個系統不crash，還是會kill掉其他各種進程。

如果那些進程不重要還好，萬一重要的話，還是會相當嚴重的。

甚至，如果操作系統找不到可以kill掉的進程，那整個系統就會crash，這個就更嚴重了。

所以，最好的方式，還是人為去避免物理內存不足的情況，在機器上跑各種程序時，要提前對整個物理內存的使用，有個規劃和預判，最好是能預留出一些內存，以防各種誤操作。

 

好了，該篇文章就講這些內容，如果以后你發現你的進程，莫名奇妙就沒有了，可以通過dmesg等方式看下內核日志，確定下你的進程是否被oom kill掉了。

本文轉載自微信公眾號「卯時卯刻」，可以通過以下二維碼關注。轉載本文請聯系卯時卯刻公眾號。