Hadoop節(jié)點(diǎn)上負(fù)載過(guò)高的問(wèn)題分析

最近發(fā)現(xiàn)我們的hadoop集群的客戶端機(jī)器負(fù)載經(jīng)常飆到幾百，導(dǎo)致機(jī)器反應(yīng)很慢， 客戶反應(yīng)無(wú)法提交job，或者job跑的很慢。

針對(duì)這種情況通常有幾個(gè)解決方案，一個(gè)是增加客戶端機(jī)器數(shù)量，把他們做到一個(gè)pool里面，根據(jù)系統(tǒng)負(fù)載情況來(lái)自動(dòng)切換不同的客戶端機(jī)器，也叫負(fù)載均衡這個(gè)我們已經(jīng)做到了；一個(gè)是找出負(fù)載高的根源，因?yàn)槿绱烁叩呢?fù)載是很不尋常的表現(xiàn)，通常是因?yàn)橄到y(tǒng)參數(shù)不對(duì)或者應(yīng)用程序有bug。

現(xiàn)象

用perf top觀察占用最多cpu time的程序，發(fā)現(xiàn)大部分是compaction.c這個(gè)程序造成的。

可以通過(guò)如下命令抓取一分鐘的記錄看下：

$ sudo perf record -a -g -F 1000 sleep 60

這里借用Brendan Gregg’s的工具 flame graph 分析下抓取的數(shù)據(jù)。

google查看后了解compaction.c 是與Transparent Huge Pages 相關(guān)的一個(gè)程序，簡(jiǎn)稱THP，THP是Redhat6 以后出現(xiàn)的功能，目的有兩個(gè)，一個(gè)是整理物理內(nèi)存的碎片，應(yīng)用程序在請(qǐng)求內(nèi)存的時(shí)候可以分到2MB的內(nèi)存（正常是4KB）；一個(gè)是應(yīng)用程序分配到的內(nèi)存不能被交換到swap。

這個(gè)特性當(dāng)然用它的應(yīng)用場(chǎng)景，但不是任何情況下都是好的，所以要視情況而決定要不要打開(kāi)此功能。

很明顯在系統(tǒng)負(fù)載如此高的情況下，大部分cpu time都是在整理內(nèi)存碎片，因此果斷取消此功能。

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

取消后過(guò)了一會(huì)就看到了效果，負(fù)載下來(lái)了，通過(guò)打開(kāi)此功能后負(fù)載又上去了，如此問(wèn)題徹底解決了。

附

下面介紹另外一種場(chǎng)景，需要打開(kāi)THP功能的。

某日發(fā)現(xiàn)oracle機(jī)器的內(nèi)存幾乎被用完，但正常情況下不是這樣的，通過(guò)cat /proc/meminfo 發(fā)現(xiàn)Pagetables 居然有5GB，太離譜了，pagetables 是映射虛擬內(nèi)存和物理內(nèi)存地址關(guān)系的tables，這些表太多了，通過(guò)開(kāi)啟THP，結(jié)果pagetables降到了一百多MB的水平。

在實(shí)際場(chǎng)景下要看情況對(duì)待。