這期內容當中小編將會給大家?guī)碛嘘P如何解決JobTracker Heap的OOM問題，文章內容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

我們提供的服務有：成都網(wǎng)站設計、做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、平泉ssl等。為1000多家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的平泉網(wǎng)站制作公司

• 引子

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

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

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

• 解決過程

• 直接google

    在statckoverflow中有人建議調整HADOOP_CLIENT_OPT，通過增大其Xmx解決該問題，經(jīng)過嘗試后發(fā)現(xiàn)無效果。

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

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

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

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



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



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

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

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

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

1. Job已經(jīng)完成，即狀態(tài)為SUCCEEDED，F(xiàn)AILED或KILLED

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

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

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

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

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

    在集群平穩(wěn)的運行了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一直產(chǎn)生OOM錯誤。

• 心得總結

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

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

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

上述就是小編為大家分享的如何解決JobTracker Heap的OOM問題了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

名稱欄目：如何解決JobTrackerHeap的OOM問題
當前URL：http://www.chinadenli.net/article46/ggishg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、響應式網(wǎng)站、網(wǎng)站收錄、、外貿網(wǎng)站建設、標簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)