早上6點(diǎn)，我不得不開(kāi)始處理“叫醒”我的一些問(wèn)題。因?yàn)楫?dāng)這些問(wèn)題發(fā)生的時(shí)候，我的手機(jī)鈴聲響了。昏睡中的我非常不情愿地拿起了手機(jī)，檢查我是否瘋狂到將叫醒鬧鐘設(shè)在了早上5點(diǎn)。原來(lái)是監(jiān)控系統(tǒng)發(fā)現(xiàn)一個(gè)Plumbr服務(wù)死掉了。

[[252838]]

作為一名該領(lǐng)域經(jīng)驗(yàn)豐富的高手，我首先來(lái)到了咖啡機(jī)旁。我需要用一杯咖啡開(kāi)始工作。第一個(gè)問(wèn)題，在應(yīng)用崩潰之前看起來(lái)一切運(yùn)行正常。日志中沒(méi)有錯(cuò)誤，沒(méi)有告警，也沒(méi)有其他任何異常。

我們的監(jiān)控系統(tǒng)已經(jīng)察覺(jué)到進(jìn)程死掉了，并且已經(jīng)重啟了崩潰的服務(wù)。因?yàn)檠褐幸呀?jīng)有了咖啡因，我開(kāi)始收集更多的證據(jù)。30分鐘后，在/var/log/kern.log文件中發(fā)現(xiàn)了以下內(nèi)容：

Jun 4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice child 
Jun 4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB 

很顯然，我們成了Linux內(nèi)核的受害者。大家都知道，Linux建立在一些守護(hù)進(jìn)程之上。這些守護(hù)進(jìn)程被幾個(gè)看起來(lái)糟透了的內(nèi)核任務(wù)看管。所有現(xiàn)代Linux內(nèi)核都內(nèi)置了一個(gè)被稱為“內(nèi)存不足殺手”的機(jī)制，它在內(nèi)存不足的情況下會(huì)殺掉用戶進(jìn)程。當(dāng)檢測(cè)到內(nèi)存不足時(shí)，殺手會(huì)被激活并選擇一個(gè)進(jìn)程殺死。選擇機(jī)制是用啟發(fā)式算法對(duì)所有進(jìn)程進(jìn)行打分，最后選擇得分最低的進(jìn)程殺死。

理解“內(nèi)存不足殺手”

默認(rèn)情況下，Linux內(nèi)核允許進(jìn)程請(qǐng)求比當(dāng)前系統(tǒng)可用內(nèi)存更多的內(nèi)存。這是有道理的，因?yàn)榇蟛糠诌M(jìn)程從來(lái)不會(huì)用掉它們請(qǐng)求的所有內(nèi)存。就像有線網(wǎng)絡(luò)運(yùn)營(yíng)商，他們承諾每個(gè)用戶100Mbit的下載速度，這遠(yuǎn)遠(yuǎn)超出了運(yùn)營(yíng)商網(wǎng)絡(luò)的真實(shí)帶寬。因?yàn)樗麄冋J(rèn)為所有用戶不會(huì)同時(shí)達(dá)到帶寬的上限。所以，一個(gè)10Gbit的鏈路能夠很好地為100個(gè)用戶提供服務(wù)超。

這種機(jī)制的一個(gè)副作用是，一些程序會(huì)消耗系統(tǒng)內(nèi)存。這將導(dǎo)致內(nèi)存不足，使得沒(méi)有內(nèi)存頁(yè)面可以分配給進(jìn)程。你可能遇到過(guò)這種情況，只有root賬號(hào)才能殺掉offending任務(wù)。為了避免這種情況發(fā)生，殺手進(jìn)程會(huì)被啟動(dòng)，識(shí)別進(jìn)程并殺死它。

更多關(guān)于“內(nèi)存不足殺手”的內(nèi)容請(qǐng)參見(jiàn)這篇RedHad的文檔。

內(nèi)存不足殺手由誰(shuí)觸發(fā)?

現(xiàn)在，我們知道了一些背景知識(shí)，但是內(nèi)存不足殺手由誰(shuí)觸發(fā)?究竟什么原因讓我在早上5點(diǎn)被叫醒?一些調(diào)查顯示：

/proc/sys/vm/overcommit_memory中的配置允許過(guò)量使用內(nèi)存，它被設(shè)置為1，意味著每一次malloc都能夠成功申請(qǐng)到內(nèi)存。

應(yīng)用運(yùn)行在一個(gè)EC2 m1.small實(shí)例上。EC2實(shí)例默認(rèn)是不支持交換區(qū)的。

這兩點(diǎn)再加上突然增加的訪問(wèn)導(dǎo)致了我們的應(yīng)用會(huì)申請(qǐng)?jiān)絹?lái)越多的內(nèi)存以支持這些用戶。過(guò)量使用內(nèi)存配置也允許為這些進(jìn)程申請(qǐng)?jiān)絹?lái)越多的內(nèi)存，最后觸發(fā)了“內(nèi)存不足殺手”，就像它的名字那樣，殺死我們的應(yīng)用然后在半夜把我叫醒。

示例

當(dāng)我向工程師們描述這個(gè)問(wèn)題時(shí)，有一個(gè)很有興趣的工程師用一個(gè)小測(cè)試程序來(lái)復(fù)現(xiàn)這個(gè)問(wèn)題。當(dāng)在Linux(最新穩(wěn)定版Ubuntu)上編譯和加載下面的Java代碼片段時(shí)，

package eu.plumbr.demo; 
public class OOM { 
  
public static void main(String[] args){ 
    java.util.List l = new java.util.ArrayList(); 
    for (int i = 10000; i < 100000; i++) { 
                try { 
                    l.add(new int[100_000_000]); 
                } catch (Throwable t) { 
                    t.printStackTrace(); 
                } 
            } 
    } 
} 

你會(huì)發(fā)現(xiàn)類似下面的消息：Kill process (java) score 或犧牲子進(jìn)程的消息。

注意：你可能需要修改交換區(qū)和堆大小。在我的測(cè)試程序中，將堆大小通過(guò)-Xmx2g設(shè)置成2G，通過(guò)如下配置設(shè)置交換區(qū)大?。?/p>

swapoff -a 
dd if=/dev/zero of=swapfile bs=1024 count=655360 
mkswap swapfile 
swapon swapfile 

解決方案?

有很多種方法可以解決這個(gè)問(wèn)題。在我們的示例中，我們只是把系統(tǒng)遷移到一個(gè)有更大內(nèi)存的實(shí)例中。并且我還建議允許交換，但是當(dāng)咨詢過(guò)工程人員后，我意識(shí)到Java虛擬機(jī)中的垃圾回收進(jìn)程在交換時(shí)表現(xiàn)不是很好，所以這個(gè)選項(xiàng)最后沒(méi)有被采用。

其他可能有用的方案包括微調(diào)內(nèi)存不足殺手，在幾個(gè)實(shí)例間進(jìn)行負(fù)載均衡或者降低應(yīng)用的內(nèi)存需求。