1、問題描述
1.1 基本信息[Basic Information]
- 集羣規模：37+3臺物理機，每臺128G內存；CPU：2*16C；SATA磁盤，2T*12
- hadoop社區版本：**
- 商業版本：FusionInsight_HD_V100R002C60U10
- MetaStore：高斯數據庫（Postgresql）
1.2 問題描述[Problem Description]
- C60U10版本YARN集羣在高併發任務狀態下運行2天左右可能導致NM資源本地化性能下降，進而導致任務整體執行效率下降。
2、問題分析[Problem Analysis]
1. 分析job性能變慢，主要體現爲Container localized執行變慢
Task Slow logs:
Task Quick logs:
通過分析日誌發現, container 執行變慢主要卡在ResourceLocalizationService鎖的競爭上：
下圖爲隨機挑選出來的一個container運行慢的時候的jstack打印信息，發現這個container等待這個鎖等待了22s之久：
2. 分析鎖內代碼執行慢的原因：
通過獲取操作系統的統計數據osinfo，發現在container localized過程中會調用ls命令獲取本地目錄的文件基本信息出現了X狀態（Linux process state: X (TASK_DEAD - EXIT_DEAD), the exit status, the process is about to be destroyed.），該狀態被捕捉多次，說明這個命令執行在os層佔用時間較長。
3. 排查ls變慢的原因，發現NM的堆外內存持續增長
1） NM的內存使用持續增長：
2）通過打印NM的堆外內存使用，發現大部分堆外內存使用均來自leveldb，內存分析截圖如下：
利用pmap命令將NM使用的內存信息dump下來，然後用gdb將指定尋址空間的堆外內存dump到本地：
通過將二進制內存文件轉化爲可見字符，可知，當前的堆外內存主要來自leveldB。
4. NM堆外內存的持續上漲到一定程度後，會導致NM內部調用os的命令執行變慢，從而導致YARN的NM的container本地化鎖競爭加劇，最終導致業務性能下降。最後，通過在生產環境上將NM的recovery特性關閉，消除了levelDB導致堆外內存持續上漲的問題，從而解決了業務執行48小時後會出現性能下降的問題。
3、根本原因[Root Cause]
分析爲YARN的recovery特性會依賴leveldb，而leveldb的數據存儲會佔用堆外內存，從而導致堆外內存上漲，當堆外內存的堆積會導致os佔用內存無法及時的釋放，而在大量任務併發時，業務也需要佔用大量內存，內存的緊張會導致任務在資源本地化的過程中執行os的“ls -ld” 命令變慢；同時每個contaienr的localized地方存在鎖的競爭，命令執行變慢，會使該鎖的競爭惡化，從而表現在業務運行一段時間後，性能逐漸變慢。
4、解決措施[Corrective Action]
4.1 最終解決措施[Solution]
- 通過關閉YARN的NodeManager的recovery特性，即配置yarn.nodemanager.recovery.enabled參數爲：false
4.2 最終解決措施[Solution]
- 解決leveldb堆外內存上漲（C60U10SPC003補丁）
- 優化container 本地化鎖（C60U10SPC003補丁）
- 將leveldb的數據目錄規劃到數據盤，不掛載到系統盤上（磁盤規劃）