如何解決JobTracker Heap的OOM問題

這期內容當中小編將會給大家帶來有關如何解決JobTracker Heap的OOM問題，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

• 引子

最近新上了9107渠道的實驗。

從實驗方法上，相比于之前的9105渠道只是簡單地對過去6小時的正例數據進行翻倍，9107則以當前時間為基準，使用指數函數對合并后訓練數據中的正例進行增益。

從具體的實現而言，為了實現的簡單，實驗的ETL部分依舊沿用Hadoop進行ETL合并處理，但后續的Sampling和Filtering則采用python單機實現。經過流程和數據測試無誤后上線，但結果老集群的JobTracher總是在跑了70多個Job之后就報出Heap OOM異常(java.lang.OutOfMemoryError: Java heap space)。

• 解決過程

• 直接google

    在statckoverflow中有人建議調整HADOOP_CLIENT_OPT，通過增大其Xmx解決該問題，經過嘗試后發現無效果。

• 突然發現java_pidxxxxx.hprof文件，搜索相關資料，發現Eclipse中的MAT工具，分析可能為JT的問題

    hprof為當虛擬機中發生OOM錯誤時，自動對Heap進行轉儲生成的二進制文件。在啟動進程時，可以通過添加參數-XX:+HeapDumpOnOutOfMemoryError開啟該功能。


    MAT(Memory Analyzer)為Eclipse中一分析hprof文件的工具，可以通過Eclipse中的'Install New Software'進行集成。需要注意的一點是，當生成的hprof文件過大的時候，需要適當增大eclipse的啟動Xmx，其配置文件為安裝目錄下的eclipse.ini。


    通過MAT打開生成的hprof文件，如下圖所示，會給出幾條Problem Suspect，在本文中，說明是由于JobTracker的占用內存過大導致的OOM。



    但是之前JobTracker穩定運行了好長時間，很少發生過該種現象，所以繼續嘗試使用MAT進行進一步的分析。通過對'dominator tree'一項進行分析發現，JobTracker中絕大部分的內存都是由JobInProgress占用的，其結果如下圖所示。



    至此，問題算是已經定位出來，但是之前的JobTracker跑了上千的Job也從來沒有發生過該種問題，為什么這次只跑了70+個Job就發生了這種情況。

• 翻閱"Hadoop技術內幕"，了解JobTracker的主要作用

    google搜索并沒有這方面很好地解答，就找了"Hadoop技術內幕"一書中關于JobTracker的一章節進行學習。有一點特別引起了我的注意，原來JobTracker在啟動的時候會啟動一些重要的線程和服務，其中有一個retireJobsThread線程。


    對于retireJobsThread線程而言，它可以清理長時間駐留在內存的已經運行結束的Job信息(即JobInProgress對象的信息)。而將JobInProgress對象保存在內存中，則是為了方便外部對歷史的Job信息進行查詢。但由于JobInProgress對象會占用過多的內存，所以當Job同時滿足條件a,b或是a,c時，就會被標志為過期的作業。

1. Job已經完成，即狀態為SUCCEEDED，FAILED或KILLED

2. Job完成時間距離當前已經24小時（可以通過mapred.jobtracker.retirejob.interval調整）

3. Job擁有者已完成的Job數量大于100（可以通過mapred.jobtracker.completeuserjobs.maximum調整）

    顯然正是由于Job的retire機制，避免了JobTracker占用內存的無線膨脹。雖然解決了JobTracker占用內存的無限膨脹問題，但是為什么之前的JobTracker就能維護100個JobInProgress，而現在就不可以了呢？9105和9107渠道到底差到了什么地方了呢？

    突然間，想到了是不是由于ETL Job占用的內存信息過大，導致當前2G的HeapSize放不下這100條JobInProgress信息呢。于是，將hadoop-env.sh中的HADOOP_HEAPSIZE從2000調整到了4000，問題神奇的就沒有再出現過。那么究竟是為什么ETL Job會比Sampling Job和Filtering Job占用更多的內存呢？于是就有了最后一步...

• 實際實驗測試，使用jmap生成hprof文件，分析與預期的結果

    在集群平穩的運行了100+個Job之后，使用jmap工具dump出來了一份JobTracker的hprof文件。再次使用MAT對其進行分析，結果如下圖所示：




    由圖可以看出以下幾點：

1. JobTracker的內存占用一直保持在1.7G左右

2. 針對于JobInProgress占用內存過大的原因，完全是由于其需要調度的TaskInProgress過多（一般為2K-3K個），從而比Sampling和Filtering耗費掉更多的內存

    至此，問題解決，確實是因為9107渠道只保留了9105渠道的ETL Job，導致多個ETL JobInPregress累計占用內存遠大于之前的9105實驗，從而造成JobTracker一直產生OOM錯誤。


• 心得總結

• 說起來，問題的解決多多少少還是存在一定的偶然性，歸根結底還是在于對Hadoop平臺一些基礎組件的底層實現不熟悉，從而導致問題定位慢，走了不少的彎路

• MAT確實是一個特別強大的工具，針對于JVM的OOM錯誤而言，通過使用MAT能夠非常方便的定位問題的根結。后續對MAT的學習使用還需要進一步的加強。

• 對于正常運行中的java進程，可以使用jmap的jmap -dump:format=b,file=xx pid命令生成hprof文件，從而分析某一時刻進程中內存的詳細使用情況

上述就是小編為大家分享的如何解決JobTracker Heap的OOM問題了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。