前言

從去年下半年開始，組內就開始著手準備升級公司內部的Hadoop叢集，由於老版本實在已經落後社群很多了，也陸續碰到很多社群上已經被fix的bug。所以決定做一個大膽的舉動：升級公司內部大叢集版本。像這種比較aggressive的做法，很多人不是一開始能夠接受，它存在不可控的風險。但所幸，在今年暑假，我們成功將內部版本升到了最近比較新的Hadoop版本。本文是對此過程的經驗教訓，相信會給很多想要做Hadoop Rolling Upgrade的同學有所幫助。

Rolling Upgrade相容性測試

我們此次升級採用的不是停服務的方式，而是Rolling Upgrade的方式，也算是對我們團隊的一個考驗吧。所以在這裡面，要做大量的相容性測試。因為rolling的過程中，會存在新老版本（NN，DN，RM和NN）共存的情況。再加上同時在跑的YARN，情況組合起來還是挺多的。不過，測試下來，除了HDFS新版本特性異構儲存（StorageType）出現明顯不相容錯誤

升級後的效能不穩定問題

其實前期相容性測試做的足夠完善的情況下時，整個Rolling Upgrade的過程問題不大。按照官方文件的建議，從NN開始升級，然後DN一點點的rolling替換即可，使用者應用對此無感知。

但是後面我們怎麼也沒料到，在新的升級後的版本執行過程中，出現了嚴重的效能不穩定問題，主要表現為RPC週期性變慢，到最慢的時候，延時已經達到秒級別，甚至到了使用者都無法正常使用的情況。但是每次一重啟NN，這個問題立馬恢復，然後過一段時間，又開始變慢。

Jvm層面調優

像這種系統逐漸變慢的問題，我們的第一反應，HDFS本身應該是沒問題，可能是jvm層面，比如某些資源沒有被回收的問題，或gc引數沒配對。於是乎，我們加了以下對我們有用的引數：

1).調整NN heap大小，之前總heap設定過大，導致其幾乎不full gc，這樣導致jvm中的大量垃圾資料一直得不到清理，加重Jvm本身的記憶體管理。得到的教訓是，不是說不讓程序full gc就是好的操作。經過這個調整之後，緩慢週期得到了適當的延長，但是還是沒有根本解決，：(。
2).增加更細粒度的jvm控制引數，如下：

• XX:+PrintTenuringDistribution 檢視每次minor GC後新的存活週期的閾值，為新生代的比例調整提供依據
• -XX:+PrintHeapAtGC 列印GC前後的詳細堆疊資訊
• -XX:+PrintGCApplicationStoppedTime 列印JVM應用停頓時間
• -XX:-UseBiasedLocking 禁用偏向鎖（在存在大量鎖物件的建立並高度併發的環境下禁用偏向鎖能夠帶來一定的效能優化）

期間，我們也有關注過是否是jvm的Code Cache區滿了，導致系統響應變慢呢，Code Cache用於儲存jvm JIT產生的編譯程式碼。

HDFS系統層面優化

在jvm層面的優化都做完後，我們發現NN還是會出現週期性變慢的情況。於是乎，又將目光轉向了HDFS系統本身。我們對內部的HDFS環境，結構部署做了考量之後，打算對HDFS開啟一輪輪的優化，然後看看問題最終出在哪裡。截止目前為止，我們做了以下優化（都是大規模叢集中通常也會採用的）：

• NN，JN分離部署，這個很重要，JN同步慢了，直接影響NN的RPC處理
• 開啟async editlog功能
• Fair Call Queue開啟，解決潛在的RPC擁塞問題，延用預設引數即可
• Fsimage壓縮功能開啟，同時對fsimage的傳輸做頻寬限速設定，這可以減少SBN向ANN，同步fsimage時造成的瞬時RPC毛刺（因為當時2者之間會佔用大量頻寬）。
• NN刪除操作相關優化。新版本的NN刪除對我們來說，算是我們踩得比較大的一個坑。新版本的HDFS對DN的塊儲存結構做了優化，用新的結構FoldedTreeSet取代原本的LightWeightGSet（詳見HDFS-9260）。前者在記憶體利用率上會跟高，但是對應地它不利於塊的update，也就是我們的刪除塊操作這種方式。本來NN在刪除大的檔案目錄時，會出現嚴重的響應延時問題，加上這個改動，這種延時的表現就更加明顯了。感興趣的同學，可以關注HDFS-13671（Namenode deletes large dir slowly caused by FoldedTreeSet#removeAndGet）。這個我們調整了FoldedTreeSet的碎片閾值引數。還有一個小的優化點，是可配置化了刪除操作的批量間隔時間。

以上就是我們對HDFS層面的優化改造。以上都是我們最近一段時間踩過的坑，和經驗總結。

引用

[1].https://issues.apache.org/jira/browse/HDFS-13671. Namenode deletes large dir slowly caused by FoldedTreeSet#removeAndGet
[2].https://issues.apache.org/jira/browse/HDFS-9260. Improve the performance and GC friendliness of NameNode startup and full block reports