Amazon Elastic MapReduce - SIGTERM

我有一個通常工作正常的EMR流作業（Python）（例如10臺機器處理200個輸入）。然而，當我運行它針對大數據集（12個機加工總共6000個輸入，在每個輸入大約20秒），2.5小時嘎吱嘎吱我得到以下錯誤的後：Amazon Elastic MapReduce - SIGTERM

java.lang.RuntimeException: PipeMapRed.waitOutputThreads(): subprocess failed with code 143 
at org.apache.hadoop.streaming.PipeMapRed.waitOutputThreads(PipeMapRed.java:372) 
at org.apache.hadoop.streaming.PipeMapRed.mapRedFinished(PipeMapRed.java:586) 
at org.apache.hadoop.streaming.PipeMapper.close(PipeMapper.java:135) 
at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:57) 
at org.apache.hadoop.streaming.PipeMapRunner.run(PipeMapRunner.java:36) 
at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:441) 
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:377) 
at org.apache.hadoop.mapred.Child$4.run(Child.java:255) 
at java.security.AccessController.doPrivileged(Native Method) 
at javax.security.auth.Subject.doAs(Subject.java:396) 
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1132) 
at org.apache.hadoop.mapred.Child.main(Child.java:249)

如果我在讀這是正確的，子程序因代碼143失敗，因爲有人向流作業發送了SIGTERM信號。

我的理解是否正確？如果是這樣的話：EMR基礎架構何時發送SIGTERM？

來源

2012-08-15 slavi

您是否檢查了CloudWatch指標以查看您是否達到某種類型的IO限制？從我的經驗來看，一旦你達到IO極限，一些奇怪的事情開始發生。我不知道您用於數據節點的實例類型，但是我建議在運行更大的作業時升級到更快的IO性能。 – Edenbauer 2012-08-16 00:39:17

事情是，每個任務都是CPU限制的，具有罕見和零星的I/O。它的功能是從S3加載一個文件，然後大約20秒完成大量CPU處理。每隔5秒它就會向S3存儲另一個（中間）文件。它使用了一些外部庫（lxml，scikit-learn），並且我認爲其中一個可能會讓我失敗（由於內存消耗急劇上升？），而EMR基礎架構正在發送一個SIGTERM。爲了驗證這一點，我試圖瞭解EMR可能會發生什麼情況時的情況。 – slavi 2012-08-16 08:18:31

我想清楚發生了什麼，所以如果其他人遇到類似的問題，這裏有一些信息。

我的關鍵是看「jobtracker」日誌。這些生活在你的任務的日誌上S3 /文件夾下：

<logs folder>/daemons/<id of node running jobtracker>/hadoop-hadoop-jobtracker-XXX.log.

有以下類型的多行：

2012-08-21 08:07:13,830 INFO org.apache.hadoop.mapred.TaskInProgress 
    (IPC Server handler 29 on 9001): Error from attempt_201208210612_0001_m_000015_0: 
    Task attempt_201208210612_0001_m_000015_0 failed to report status 
    for 601 seconds. Killing!

所以我的代碼是超時，並且它被殺害（它超出了10分鐘任務超時）。 10分鐘我沒有做任何I/O，這當然不是預期的（我通常會每20秒做一次I/O）。

然後我發現了這篇文章：。

http://devblog.factual.com/practical-hadoop-streaming-dealing-with-brittle-code

「在我們的科學項目之一，我們有超過紅寶石運行，並依靠libxml的幾個Hadoop的流工作來解析文檔這將創建一個完美的糟糕的風暴 - 網頁充滿了非常糟糕的html，而libxml偶爾會進入無限循環或完全段錯誤，在某些文檔中，它總是出現段錯誤。

它釘了它。我必須遇到這些「libxml進入無限循環」的情況之一（我正在大量使用libxml - 僅限於Python，而不是Ruby）。

對我來說，最後一步是觸發跳過模式（說明在這裏：Setting hadoop parameters with boto?）。

來源

2012-08-22 11:21:26 slavi

感謝您發佈自己問題的答案。這幫助我調試了一個類似的問題。 – 2012-11-12 19:41:51

同上，我正在運行一個mrjob hadoop作業，該作業在原始問題中發佈的內容沒有輸出，失敗。這是幫助我找到根本原因的唯一有用日誌（hadoop2映射容器內存不足）。 – jonson 2015-02-18 23:56:46

我跑到Amazon EMR的輸出中（「子程序失敗，代碼143」）。我的流式作業使用PHP curl將數據發送到沒有安全組的MapReduce作業服務器部分的服務器。因此減速器超時並被殺死。理想情況下，我想將我的作業添加到同一個安全組，但我選擇僅添加我的API的URL安全令牌參數。

來源

2013-05-06 20:48:58 creoe

Amazon Elastic MapReduce - SIGTERM

回答

相關問題