先來看段代碼：

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

運行下。

沒啥問題，和我們預(yù)期的一樣，正常執(zhí)行。

打開另一個終端，執(zhí)行以下命令，看下它的內(nèi)存占用：

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

我們再開個終端，再執(zhí)行下這個程序。

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

這是為什么呢？

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

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

在第二次執(zhí)行該程序，且向操作系統(tǒng)申請物理內(nèi)存時，操作系統(tǒng)會發(fā)現(xiàn)，物理內(nèi)存已經(jīng)沒有了。

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

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

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

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

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

那為什么不在第二次執(zhí)行該程序時，在調(diào)用mmap分配虛擬內(nèi)存時就直接報錯，返回?zé)o法分配內(nèi)存呢？

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

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

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

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

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

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

這個和linux內(nèi)核中oom killer的選擇策略有關(guān)，我們直接看源碼：

當進程請求操作系統(tǒng)為其分配物理內(nèi)存時，如果此時物理內(nèi)存已經(jīng)沒有了，則會觸發(fā)上圖中的out_of_memory函數(shù)。

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

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

該函數(shù)調(diào)用了__oom_kill_process：

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

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

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

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

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

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

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

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

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

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

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

points = 該進程占用的物理內(nèi)存總數(shù) +總物理內(nèi)存 * oom_score_adj值的千分比。

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

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

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

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

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

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

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

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

其實，調(diào)整linux內(nèi)核中oom killer行為的方式有很多，不止修改oom_score_adj值這一種方法。

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

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

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

oom killer行為調(diào)整的相關(guān)參數(shù)，其具體詳解可以看proc的man文檔：

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

聊了這么多，那理解linux內(nèi)核的oom killer機制，對于我們實際應(yīng)用有哪些幫助呢？

我們假設(shè)以下場景：

假如，我們有一臺機器，上面跑著一個非常重要的服務(wù)，比如數(shù)據(jù)庫，或者某個應(yīng)用進程等。

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

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

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

那怎么避免呢？

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

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

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

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

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

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

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

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

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

原文標題：為什么我的進程被kill掉了

文章出處：【微信公眾號：Linux閱碼場】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq