最近發現我們的hadoop集羣的客戶端機器負載經常飆到幾百，導致機器反應很慢， 客戶反應無法提交job，或者job跑的很慢。
針對這種情況通常有幾個解決方案，一個是增加客戶端機器數量，把他們做到一個pool裏面，根據系統負載情況來自動切換不同的客戶端機器，也叫負載均衡這個我們已經做到了；一個是找出負載高的根源，因爲如此高的負載是很不尋常的表現，通常是因爲系統參數不對或者應用程序有bug。
現象
用perf top觀察佔用最多cpu time的程序，發現大部分是compaction.c這個程序造成的。
可以通過如下命令抓取一分鐘的記錄看下：
$ sudo perf record -a -g -F 1000 sleep 60
這裏借用Brendan Gregg’s的工具 flame graph 分析下抓取的數據。
google查看後瞭解compaction.c 是與Transparent Huge Pages 相關的一個程序，簡稱THP，THP是Redhat6 以後出現的功能，目的有兩個，一個是整理物理內存的碎片，應用程序在請求內存的時候可以分到2MB的內存（正常是4KB）；一個是應用程序分配到的內存不能被交換到swap。
這個特性當然用它的應用場景，但不是任何情況下都是好的，所以要視情況而決定要不要打開此功能。
很明顯在系統負載如此高的情況下，大部分cpu time都是在整理內存碎片，因此果斷取消此功能。
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
取消後過了一會就看到了效果，負載下來了，通過打開此功能後負載又上去了，如此問題徹底解決了。
附
下面介紹另外一種場景，需要打開THP功能的。
某日發現oracle機器的內存幾乎被用完，但正常情況下不是這樣的，通過cat /proc/meminfo 發現Pagetables 居然有5GB，太離譜了，pagetables 是映射虛擬內存和物理內存地址關係的tables，這些表太多了，通過開啓THP，結果pagetables降到了一百多MB的水平。
在實際場景下要看情況對待。