Hadoop MapReduce作業(yè)卡死問題的解決方法_第1頁
Hadoop MapReduce作業(yè)卡死問題的解決方法_第2頁
Hadoop MapReduce作業(yè)卡死問題的解決方法_第3頁
Hadoop MapReduce作業(yè)卡死問題的解決方法_第4頁
Hadoop MapReduce作業(yè)卡死問題的解決方法_第5頁
已閱讀5頁,還剩6頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1、 Hadoop MapReduce 作業(yè)長時(shí)間卡死問題的解決方法 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66483126 1. 問題描述 PAGEREF _Toc66483126 h 3 HYPERLINK l _Toc66483127 2. 問題分析 PAGEREF _Toc66483127 h 3 HYPERLINK l _Toc66483128 2.1. 數(shù)據(jù)傾斜可能性分析 PAGEREF _Toc66483128 h 3 HYPERLINK l _Toc66483129 2.2. Hadoop集群組件狀態(tài)分析 PAGEREF _Toc66483129

2、h 4 HYPERLINK l _Toc66483130 2.3. 日志分析 PAGEREF _Toc66483130 h 4 HYPERLINK l _Toc66483131 2.4. 作業(yè)運(yùn)行外圍情況分析 PAGEREF _Toc66483131 h 8 HYPERLINK l _Toc66483132 2.5. 分析小結(jié) PAGEREF _Toc66483132 h 9 HYPERLINK l _Toc66483133 3. 問題解決 PAGEREF _Toc66483133 h 91. 問題描述當(dāng)前,我們通過編寫Hadoop MapReduce程序?qū)碜陨嫌蔚脑磾?shù)據(jù)文件進(jìn)行貼源預(yù)處理加

3、工。源數(shù)據(jù)文件發(fā)到Hadoop集群后,我們的預(yù)處理程序會對源數(shù)據(jù)進(jìn)行編碼轉(zhuǎn)換、數(shù)據(jù)去重、加時(shí)間拉鏈、數(shù)據(jù)清洗、錯(cuò)誤數(shù)據(jù)處理等操作,生成貼源的ODS層數(shù)據(jù),供上層建模使用。一直以來系統(tǒng)運(yùn)行穩(wěn)定,未出現(xiàn)過問題。但一段時(shí)間以來部分源文件的預(yù)處理作業(yè)頻繁出現(xiàn)作業(yè)長時(shí)間卡死的問題,導(dǎo)致Hadoop集群資源被長時(shí)間占用,其他作業(yè)因資源不足而無法正常調(diào)起,影響了預(yù)處理加工的時(shí)效性。對此我們從各方面進(jìn)行了分析和處理,具體過程如下。2. 問題分析2.1. 數(shù)據(jù)傾斜可能性分析當(dāng)問題出現(xiàn)時(shí),我們首先考慮到可能是因?yàn)閿?shù)據(jù)傾斜問題導(dǎo)致了作業(yè)長時(shí)間卡死的現(xiàn)象。于是我們首先檢查YARN控制臺的作業(yè)信息如圖2-1:圖2-1

4、YARN控制臺reduce任務(wù)運(yùn)行情況從上圖可以看到有大量的reduce任務(wù)長時(shí)間運(yùn)行,而非少部分reduce任務(wù)長時(shí)間運(yùn)行。數(shù)據(jù)傾斜的典型現(xiàn)象是大部分reduce任務(wù)執(zhí)行時(shí)間較短,只有很少的reduce任務(wù)長時(shí)間運(yùn)行,可以說上圖反映的情況與數(shù)據(jù)傾斜并不完全相符,同時(shí),我們也對MR程序處理的源數(shù)據(jù)文件進(jìn)行了按Key值分組計(jì)算,發(fā)現(xiàn)并未有數(shù)據(jù)分布不均衡的情況,因此我們排除了因數(shù)據(jù)傾斜導(dǎo)致作業(yè)卡死的可能性。2.2. Hadoop集群組件狀態(tài)分析通過查看Hadoop集群UI頁面上各組件狀態(tài)以及查看NameNode、DataNode、ResouceManager等系統(tǒng)服務(wù)日志信息,可以確認(rèn)集群及各組件

5、沒有問題,運(yùn)行正常,從而排除因集群本身問題導(dǎo)致作業(yè)卡死。2.3. 日志分析我們發(fā)現(xiàn)這些長時(shí)間運(yùn)行的作業(yè)都是卡死在reduce階段,有大量reduce任務(wù)卡在27%-30%進(jìn)度不再運(yùn)行,如圖2-1所示。同時(shí)也有部分map任務(wù)和reduce任務(wù)失敗。于是我們查看了該作業(yè)的如下日志信息:1)通過yarn -logs獲取的job日志:2)job對應(yīng)的容器日志為如圖2-2和圖2-3所示圖2-2 異常作業(yè)容器信息1圖2-3 異常作業(yè)容器信息23)失敗map任務(wù)日志:圖2-4 失敗map任務(wù)日志4)失敗reduce任務(wù)日志:圖2-5 失敗reduce任務(wù)日志5)長時(shí)間卡死的reduce任務(wù)的syslog日志

6、:6)長時(shí)間卡死的reduce任務(wù)的syslog.shuffle的日志:7)長時(shí)間卡死的reduce任務(wù)的進(jìn)程棧根據(jù)上述日志進(jìn)行如下分析:(1)job日志中異常1:communication thread org.apache.hadoop.mapred.Task: Communicationexception。這個(gè)是任務(wù)的一種狀態(tài)報(bào)告機(jī)制,當(dāng)出現(xiàn)異常時(shí)會有重試機(jī)制(默認(rèn)為3次)。后續(xù)沒有出現(xiàn)異常,則說明已恢復(fù)正常,不需要關(guān)注.(2)job日志中異常2:communication threadorg.apache.hadoop.yarn.util.ProcfsBasedProcessTree:

7、 Error reading the streamjava.io.IOException: 沒有那個(gè)進(jìn)程。出現(xiàn)該異常信息后,任務(wù)持續(xù)卡住長達(dá)11小時(shí),在任務(wù)界面上依然是running狀態(tài),原因不明。(3)失敗map任務(wù)和失敗reduce任務(wù)日志顯示任務(wù)超時(shí),容器被killed,對應(yīng)的進(jìn)程退出碼為143。從UI日志截圖顯示的任務(wù)超過10分鐘無響應(yīng)(對應(yīng)yarn容器配置中mapreduce.task.timeout=10分鐘)而被kill掉。該情況通常發(fā)生在任務(wù)高并發(fā)、IO競爭激烈的場景下,考慮優(yōu)化超時(shí)時(shí)間、容器內(nèi)存配置等參數(shù)。但該問題不是導(dǎo)致作業(yè)卡死的原因,如果超長reduce任務(wù)可以超時(shí)被ki

8、ll也不會出現(xiàn)本文之前描述的情況。(4)對于長時(shí)間卡死的reduce任務(wù)的syslog日志中“IOException: 沒有那個(gè)進(jìn)程”異常,一般是讀取“/proc/meminfo”、“/proc/cpuinfo”等本地文件時(shí)出現(xiàn),正常情況下任何用戶都可以訪問這些文件,初步診斷為可能是沒有更多的文件描述符來打開/proc/下對應(yīng)進(jìn)程文件的信息。通過“ulimit -n”查詢發(fā)現(xiàn)所有的節(jié)點(diǎn)配置所有用戶對應(yīng)的打開文件數(shù)為100000,在系統(tǒng)繁忙時(shí)可能有些偏少,后續(xù)考慮提升至150000。但這不是導(dǎo)致作業(yè)卡死的原因。(5)通過查看長時(shí)間卡死的reduce任務(wù)的syslog.shuffle日志,可以發(fā)現(xiàn)

9、對應(yīng)的shuffle任務(wù)在較短的時(shí)間內(nèi)就處理了大量的map結(jié)果,但是shuffer任務(wù)本身日志中并沒有報(bào)錯(cuò),呈現(xiàn)任務(wù)卡死現(xiàn)象,原因不明。(6)因上述日志沒有查到任務(wù)長時(shí)間卡死的線索,我們又查了卡死reduce任務(wù)進(jìn)程的堆棧信息,從堆棧信息中,我們發(fā)現(xiàn)reduce任務(wù)獲取map任務(wù)完成事件的線程狀態(tài)是阻塞,也就是說reduce任務(wù)在等待map任務(wù)完成的信號但一直沒收到,而事實(shí)上該job的所有map任務(wù)都已經(jīng)完成,這導(dǎo)致整個(gè)作業(yè)卡死,在高并發(fā)情況下會偶現(xiàn)這種情況。之所以reduce沒有觸發(fā)超時(shí)kill機(jī)制是reduce任務(wù)的ping心跳發(fā)送本身并沒有異常,而事件獲取線程也并未退出(若因異常退出,會

10、直接導(dǎo)致reducetask異常而重跑任務(wù))。我們進(jìn)一步查了job的如下三個(gè)參數(shù):ipc.client.ping=erval=60000ipc.client.rpc-timeout.ms=0因設(shè)置了基于TCP的Socket的網(wǎng)絡(luò)超時(shí)時(shí)間,當(dāng)任務(wù)節(jié)點(diǎn)讀取數(shù)據(jù)時(shí)發(fā)生SocketTimeoutException時(shí),會自動的向服務(wù)器端發(fā)送ping包,來測試當(dāng)前客戶端與服務(wù)器端的連接是否正常,對應(yīng)的參數(shù)為erval(默認(rèn)為60000ms)。ipc.client.rpc-timeout.ms是RPC客戶端等待相應(yīng)的超時(shí)時(shí)間值,當(dāng)參數(shù)的值為0時(shí),在遠(yuǎn)程

11、方法調(diào)用沒有接受到數(shù)據(jù)的情況下,只要ping服務(wù)正常,就不會超時(shí),而只會按erval時(shí)間間隔不停發(fā)出ping服務(wù),如果有ipc.client.rpc-timeout.ms0,該時(shí)間內(nèi)未收到遠(yuǎn)程方法返回的數(shù)據(jù)即超時(shí),隨即停止發(fā)送ping服務(wù),從而可以有效避免卡死。當(dāng)前集群ping發(fā)送機(jī)制是打開的,每1分鐘定期向服務(wù)器發(fā)送ping服務(wù),但是超時(shí)時(shí)間設(shè)置為0,即永不超時(shí),會一直處于讀取map數(shù)據(jù)的階段,這也就是AM一直認(rèn)為該reduce任務(wù)還活著而沒有按照任務(wù)超時(shí)機(jī)制將其kill。這樣問題的核心原因基本找到了。2.4. 作業(yè)運(yùn)行外圍情況分析在分析日志的同時(shí),我們也關(guān)注了作業(yè)卡

12、死時(shí)段的其他外圍情況:1)有大量作業(yè)在該時(shí)段被調(diào)起;2)近期集群進(jìn)行了擴(kuò)容,正在進(jìn)行數(shù)據(jù)均衡操作中,節(jié)點(diǎn)間IO競爭激烈;3)鑒于hadoop的任務(wù)分配原則(本地?cái)?shù)據(jù)優(yōu)先,計(jì)算在數(shù)據(jù)所在節(jié)點(diǎn)上進(jìn)行的原則),在任務(wù)高峰期,某些節(jié)點(diǎn)IO競爭激烈,會導(dǎo)致任務(wù)超時(shí)現(xiàn)象發(fā)生。2.5. 分析小結(jié)綜上,可以得到如下結(jié)論:1)ipc.client.rpc-timeout.ms=0參數(shù)設(shè)置不合理,無超時(shí)退出機(jī)制,導(dǎo)致在高并發(fā)、IO競爭激烈的場景下,觸發(fā)了任務(wù)長時(shí)間卡死的問題;2)節(jié)點(diǎn)文件描述符數(shù)偏低,導(dǎo)致任務(wù)執(zhí)行中出現(xiàn)“IOException: 沒有那個(gè)進(jìn)程”異常;3)超時(shí)時(shí)間、容器內(nèi)存配置等參數(shù)不夠優(yōu)化,導(dǎo)致部

13、分任務(wù)超時(shí)失敗退出,影響job執(zhí)行;4)大量作業(yè)并發(fā)和數(shù)據(jù)均衡操作一定程度上加劇了IO的競爭程度,間接觸發(fā)了卡死問題的出現(xiàn)。其中1)是產(chǎn)生問題的主要因素。3. 問題解決問題原因找到就好制定處理方案了,我們通過控制作業(yè)并發(fā)、降低數(shù)據(jù)均衡操作帶寬和調(diào)整如下集群參數(shù)來解決問題:上述操作執(zhí)行后,問題得到解決。經(jīng)過此次問題處理,我們也總結(jié)了一套針對Hadoop程序長時(shí)間執(zhí)行問題的解決思路:1、首先檢查是否有數(shù)據(jù)傾斜,因?yàn)榇蟛糠智闆r下是由這個(gè)原因引發(fā)Hadoop程序長時(shí)間執(zhí)行問題。數(shù)據(jù)傾斜的典型現(xiàn)象是大部分reduce任務(wù)執(zhí)行時(shí)間較短,只有很少的reduce任務(wù)長時(shí)間運(yùn)行,同時(shí)某個(gè)key對應(yīng)的數(shù)據(jù)比其他key對應(yīng)的數(shù)據(jù)多很多,一旦出現(xiàn)上述情況就可判斷是出現(xiàn)數(shù)據(jù)傾斜情況,需要對key值特別多的數(shù)據(jù)進(jìn)行單獨(dú)處理,比如在key上加隨機(jī)數(shù)把數(shù)據(jù)打散,使得數(shù)據(jù)盡可能的平均shuffle到各reduce節(jié)點(diǎn)上,充分利用各節(jié)點(diǎn)的算力。2、如果未出現(xiàn)數(shù)據(jù)傾斜的情況,那就需要先檢查集群各主要組件的運(yùn)行情況,如HDFS、YARN、Spark、Hive等,確認(rèn)各組件是否正常,有相當(dāng)一部分Hadoop程序長時(shí)間執(zhí)行問題由組件運(yùn)行問題引起。一般通過查看Hadoop集群UI頁面上各組件狀態(tài)和查

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論