2011-09-05 92 views
6

我已經在這個問題上敲了幾天頭,並希望有人在那裏有一些洞察力。Hadoop流式作業失敗:非零作業狀態爲137的任務流程退出

我已經寫了一個流式映射減少在perl中的作業,很容易有一個或兩個reduce任務需要很長時間才能執行。這是由於數據中存在一種自然不對稱:一些縮減鍵有超過一百萬行,其中大多數只有幾十行。

我以前遇到過很長時間的任務問題,並且我一直在增加計數器以確保地圖縮減不會計時。但是,現在他們正在一條錯誤消息失敗我從來沒有見過的:

java.io.IOException: Task process exit with nonzero status of 137. 
    at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:418) 

這不是標準的超時錯誤消息,但錯誤碼137 = 128 + 9建議,我減速腳本接到殺 - 9個來自Hadoop。向TaskTracker日誌包含以下內容:

2011-09-05 19:18:31,269 WARN org.mortbay.log: Committed before 410 getMapOutput(attempt_201109051336_0003_m_000029_1,7) failed : 
org.mortbay.jetty.EofException 
     at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:787) 
     at org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenerator.java:548) 
     at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:569) 
     at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:946) 
     at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:646) 
     at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:577) 
     at org.apache.hadoop.mapred.TaskTracker$MapOutputServlet.doGet(TaskTracker.java:2940) 
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) 
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) 
     at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) 
     at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363) 
     at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) 
     at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) 
     at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) 
     at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) 
     at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) 
     at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) 
     at org.mortbay.jetty.Server.handle(Server.java:324) 
     at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534) 
     at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864) 
     at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533) 
     at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207) 
     at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) 
     at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) 
     at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) 
Caused by: java.io.IOException: Connection reset by peer 
     at sun.nio.ch.FileDispatcher.write0(Native Method) 
     at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) 
     at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:72) 
     at sun.nio.ch.IOUtil.write(IOUtil.java:43) 
     at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) 
     at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:169) 
     at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:221) 
     at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:721) 
     ... 24 more 

2011-09-05 19:18:31,289 INFO org.apache.hadoop.mapred.TaskTracker.clienttrace: src: 10.92.8.202:50060, dest: 10.92.8.201:46436, bytes: 7340032, op: MAPRED_SHUFFLE, cliID: attempt_201109051336_0003_m_000029_1 
2011-09-05 19:18:31,292 ERROR org.mortbay.log: /mapOutput 
java.lang.IllegalStateException: Committed 
     at org.mortbay.jetty.Response.resetBuffer(Response.java:994) 
     at org.mortbay.jetty.Response.sendError(Response.java:240) 
     at org.apache.hadoop.mapred.TaskTracker$MapOutputServlet.doGet(TaskTracker.java:2963) 
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) 
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) 
     at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) 
     at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363) 
     at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) 
     at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) 
     at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) 
     at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) 
     at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) 
     at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) 
     at org.mortbay.jetty.Server.handle(Server.java:324) 
     at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534) 
     at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864) 
     at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533) 
     at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207) 
     at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) 
     at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) 
     at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) 

我一直在尋找周圍的論壇,它聽起來像是警告將在運行沒有錯誤的工作中常見的,並且通常可以忽略不計。該錯誤使它看起來像減速器失去與地圖輸出接觸,但我不明白爲什麼。有沒有人有任何想法?

這是一個潛在的相關事實:這些長期任務讓我的工作需要幾天時間,而這需要幾分鐘。因爲我生活中可以沒有一個或兩個鍵的輸出,我想在我的減速器實現十分鐘超時如下:

eval { 
     local $SIG{ALRM} = sub { 
      print STDERR "Processing of new merchant names in $prev_merchant_zip timed out...\n"; 
      print STDERR "reporter:counter:tags,failed_zips,1\n"; 
      die "timeout"; 
     }; 

     alarm 600; 

     #Code that could take a long time to execute 

     alarm 0; 
    }; 

此超時代碼的工作就像一個魅力,當我本地測試腳本,但奇怪的mapreduce錯誤是在我介紹它之後開始的。但是,失敗似乎在第一次超時後發生,因此我不確定它是否相關。

在此先感謝您的幫助!

+0

我忘了提,我正在使用hadoop 0.20.2。 –

回答

10

兩種可能性浮現在腦海中:

  1. RAM的使用,如果一個任務佔用過多內存的操作系統可以殺死它(恐怖交換等後)。
  2. 您是否使用任何非重入庫?也許計時器在圖書館電話的不合時宜的地方被觸發。
+0

你可以在第二個('不可重入')的PLZ elazrate嗎? – Alcott

+0

我首先會檢查第一個建議(Linux OOM殺手),因爲137的返回碼是其簽名(SIG_KILL的128 + 9)。確定你是否受到這種情況的困擾是非常直接的:egrep -i'殺死進程'/ var/log/messages,也是在這個答案中開發的:http://stackoverflow.com/a/624868/366749 –

+0

對不起 - 錯過了這個評論。某些庫(幾年前我們在Quest的auth庫中遇到了問題)不是多線程兼容的,並且它們的內核任務在它們處於活動狀態時會發生切換「不好的事情發生」。 – cftarnas

5

退出碼137是臭名昭着的OOM殺手的典型標誌。你可以很容易地檢查使用這樣的消息dmesg命令它:

[2094250.428153] CPU: 23 PID: 28108 Comm: node Tainted: G   C O 3.16.0-4-amd64 #1 Debian 3.16.7-ckt20-1+deb8u2 
[2094250.428155] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.2 03/04/2015 
[2094250.428156] ffff880773439400 ffffffff8150dacf ffff881328ea32f0 ffffffff8150b6e7 
[2094250.428159] ffff881328ea3808 0000000100000000 ffff88202cb30080 ffff881328ea32f0 
[2094250.428162] ffff88107fdf2f00 ffff88202cb30080 ffff88202cb30080 ffff881328ea32f0 
[2094250.428164] Call Trace: 
[2094250.428174] [<ffffffff8150dacf>] ? dump_stack+0x41/0x51 
[2094250.428177] [<ffffffff8150b6e7>] ? dump_header+0x76/0x1e8 
[2094250.428183] [<ffffffff8114044d>] ? find_lock_task_mm+0x3d/0x90 
[2094250.428186] [<ffffffff8114088d>] ? oom_kill_process+0x21d/0x370 
[2094250.428188] [<ffffffff8114044d>] ? find_lock_task_mm+0x3d/0x90 
[2094250.428193] [<ffffffff811a053a>] ? mem_cgroup_oom_synchronize+0x52a/0x590 
[2094250.428195] [<ffffffff8119fac0>] ? mem_cgroup_try_charge_mm+0xa0/0xa0 
[2094250.428199] [<ffffffff81141040>] ? pagefault_out_of_memory+0x10/0x80 
[2094250.428203] [<ffffffff81057505>] ? __do_page_fault+0x3c5/0x4f0 
[2094250.428208] [<ffffffff8109d017>] ? put_prev_entity+0x57/0x350 
[2094250.428211] [<ffffffff8109be86>] ? set_next_entity+0x56/0x70 
[2094250.428214] [<ffffffff810a2c61>] ? pick_next_task_fair+0x6e1/0x820 
[2094250.428219] [<ffffffff810115dc>] ? __switch_to+0x15c/0x570 
[2094250.428222] [<ffffffff81515ce8>] ? page_fault+0x28/0x30 

你可以很容易OOM是否啓用:

$ cat /proc/sys/vm/overcommit_memory 
0 

基本上OOM殺手試圖殺死進程吃內存的最大部分。並且您probably don't want to disable it

使用以下命令可以完全禁用OOM殺手。 這不建議用於生產環境,因爲如果 自身存在內存不足情況,則可能會出現意外的 行爲,具體取決於可用的系統資源和配置的 。這種意外行爲可能是從內核恐慌到掛起的任何事情,具體取決於OOM條件時內核可用的資源。如果使用例如

sysctl vm.overcommit_memory=2 
echo "vm.overcommit_memory=2" >> /etc/sysctl.conf 

相同的情況可能發生cgroups限制內存。當進程超過給定的限制時,它會在沒有警告的情況下死亡

0

我得到了這個錯誤。殺了一天,發現它是代碼中某個地方的無限循環。