009_關閉linux的THP
背景：
公司某個大型業務系統反饋最近數據庫服務器總是宕機（此處描述不準確，後面解釋），最後，客戶、運維人員都覺得實在是忍無可忍了，項目經理打電話找到我問是否能幫忙診斷一下，剛好第二天要去現場溝通另外一個系統的測試需求，於是答應第二天順便看一下。
------------------------------------
排查解決過程：
第二天來到現場，正在溝通需求的時候，運維人員突然說，操作又開始卡了，
於是連上服務器，先用top大概看了一下資源的使用情況，此時CPU已經基本上滿載了，而且可以發現用戶態的CPU占比並不高，大部分時間竟然都是內核態的CPU占用，
當時我開始懷疑可能是數據庫服務對底層的某個調用出了問題，有死循環？
於是立刻用perf top大概看了一下，
發現比重較大的是自旋鎖還有一個compaction_alloc，內存碎片整理？
從該信息判斷，可能是內存的什麽操作導致了很多線程在臨界區各種等待。
為了進一步弄明白具體是什麽操作導致，於是對內核參數的調用棧進行取樣
perf record -a -g -F 1000 sleep 60
“-g‘的意思是按照調用關系存儲數據；“-F 1000 sleep 60”表示按照每秒取1000個樣本的頻率取一分鐘。
取完樣後，使用perf report -g打開取樣的數據，可以看到如下的調用棧：
很明顯這個自旋鎖是由內存頁的碎片整理導致，而進行碎片整理是由hugepage導致的，
看到這裏的時候，我突然想起來linux的一個THP特性，貌似是kelnel 2.6.38版本後開始加進來的，
這個特性實際上就是會把這種巨頁的使用對用戶透明，用戶不需要再進行巨頁的配置，
內存會自動將連續的512個普通頁作為一個巨頁處理，
正如我們在前面的調用棧看到的，這種特性就需要對內存碎片進行整理，
所以我們看到的現象是內存碎片頁移動
知道了問題原因，解決也就容易了，只要把THP關閉就可以了。
關閉的方法如下：
vi /etc/rc.local
在文件末尾添加如下指令：
if test -f /sys/kernel/mm/redhat_transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/redhat_transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
fi
保存後，重啟即可。
PS：此處不同版本的linux路徑會有些區別，自己看好了
vi /sys/kernel/mm/redhat_transparent_hugepage/enabled
如果顯示如下：
即為關閉THP生效。
其實這樣做完還不算完全解決問題，就如我們前面說的，
THP的引入是為了減少維護人員配置巨頁的工作，我們把THP特性關掉了，
最好的實踐是我們應該再根據我們數據庫服務需要的共享內存大小進行hugepage的配置。
畢竟在現在動輒幾十G，甚至上百G的內存，如果在按照4K普通頁大小去維護TLB，也是一個很大的開銷。
這裏hugepage的配置，因為數據庫不同，甚至數據庫版本不同，配置過程也不大相同，最重要的一點，我發現這篇日誌寫的有點太長了。
因此，這裏就不展開贅述了，有時間可以開帖講一講。
-----------------------------------------------
解決效果：
在進行如上兩步處理後，連續觀察了幾天，果然再沒有所謂的“宕機”事件了。
這裏“宕機”用了引號，對應最前面反饋問題時項目經理所說的服務器宕機描述，其實這個描述本身就是錯誤的，明天我準備再針對這個詳細解釋一下：如何正確的提問。
具體操作:如何將Transparent HugePages關閉
reference:https://blog.csdn.net/scofy0/article/details/43270517
009_關閉linux的THP