先來看段代碼：

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

運(yùn)行下：

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

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

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

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

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

這是為什么呢？

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

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

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

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

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

比如上面第一個(gè)進(jìn)程被kill掉的事件記錄如下：

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

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

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

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

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

這也就解釋了為什么上面第二次運(yùn)行該程序時(shí)，mmap是沒有報(bào)錯(cuò)的。

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

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

那為什么不kill掉第二個(gè)進(jìn)程，而是kill掉第一個(gè)呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

oom_score_adj的值，是進(jìn)程獨(dú)有的，是可以通過寫 /proc/［pid］/oom_score_adj 的方式調(diào)整的，取值范圍為 -1000 到 1000。

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

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

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

各進(jìn)程的oom_score_adj的值默認(rèn)為0。

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

默認(rèn)情況下，因?yàn)楦鬟M(jìn)程的oom_score_adj的值都為0，所以進(jìn)程占用的物理內(nèi)存越大，其badness點(diǎn)數(shù)也就越大，其也就越容易被kill掉。

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

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

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

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

比如，通過修改 /proc/［pid］/oom_adj 值的方式，同樣可以達(dá)到修改 /proc/［pid］/oom_score_adj 的目的，不過這個(gè)在內(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機(jī)制，對于我們實(shí)際應(yīng)用有哪些幫助呢？

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

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

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

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

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

那怎么避免呢？

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

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

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

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

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

如果那些進(jìn)程不重要還好，萬一重要的話，還是會相當(dāng)嚴(yán)重的。

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

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

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

希望本文對你有所幫助，可以的話也幫忙點(diǎn)個(gè)贊。

原文標(biāo)題：為什么我的進(jìn)程被kill掉了

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

責(zé)任編輯：haq