Amazon Elastic MapReduce — SIGTERM

У меня есть потоковое задание EMR (Python), которое обычно работает нормально (например, 10 машин обрабатывают 200 входных данных). Однако, когда я запускаю его для больших наборов данных (12 машин, обрабатывающих в общей сложности 6000 входных данных, примерно по 20 секунд на каждый вход), после 2,5 часов обработки я получаю следующую ошибку:

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?


python amazon-emr hadoop-streaming elastic-map-reduce
person slavi    schedule 15.08.2012    source источник
comment
Проверяли ли вы метрики CloudWatch, чтобы увидеть, не превышаете ли вы какой-либо предел ввода-вывода? По моему опыту, как только вы достигаете предела ввода-вывода, начинают происходить странные вещи. Я не знаю, какой тип экземпляра вы использовали для своих узлов данных, но я бы предложил перейти на что-то с более высокой производительностью ввода-вывода при выполнении больших заданий.   -  person Edenbauer    schedule 16.08.2012
comment
Дело в том, что каждая задача привязана к центральному процессору, с редкими и спорадическими операциями ввода-вывода. Что он делает, так это загружает файл с S3, а затем в течение примерно 20 секунд выполняет много тяжелой обработки ЦП. Каждые 5 секунд он сохраняет еще один (промежуточный) файл на S3. Он использует некоторые внешние библиотеки (lxml, scikit-learn), и я подумал, что, возможно, одна из них меня подвела (из-за всплеска потребления памяти?), а инфраструктура EMR отправляла SIGTERM. Чтобы убедиться в этом, я пытаюсь понять случаи/сценарии, когда EMR может ПОДПИСАТЬ процесс.   -  person slavi    schedule 16.08.2012

Ответы (2)


arrow_upward
10
arrow_downward

Я понял, что происходит, так что вот некоторая информация, если кто-то еще испытывает подобные проблемы.

Ключом для меня было посмотреть журналы «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 минут я не выполнял никаких операций ввода-вывода, чего, конечно же, не ожидал (обычно я выполнял операции ввода-вывода каждые 20 секунд).

Затем я обнаружил эту статью:

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

«В одном из наших научных проектов у нас есть несколько заданий Hadoop Streaming, которые выполняются на Ruby и полагаются на libxml для анализа документов. Это создает идеальный шторм зла — в Интернете полно действительно плохого html, а libxml иногда зацикливается. или прямые ошибки сегментации. В некоторых документах всегда возникают ошибки сегментации».

Это прибило его. Я должен столкнуться с одной из таких ситуаций, когда "libxml переходит в бесконечный цикл" (я интенсивно использую libxml - только с Python, а не с Ruby).

Последним шагом для меня было активировать режим пропуска (инструкции здесь: Настройка параметров hadoop с помощью boto?).

person slavi    schedule 22.08.2012
comment
Спасибо, что опубликовали ответ на свою проблему. Это помогло мне отладить аналогичный, который у меня есть. - person Michael Barton; 12.11.2012
comment
То же самое, я выполнял задание mrjob hadoop, которое не дало никаких результатов, кроме того, что было опубликовано в исходном вопросе. Это был единственный полезный журнал, который помог мне найти основную причину (контейнеру картографа Hadoop2 не хватало памяти). - person jonson; 19.02.2015

arrow_upward
1
arrow_downward

Я столкнулся с этим выводом из Amazon EMR («сбой подпроцесса с кодом 143»). Мое потоковое задание использовало PHP curl для отправки данных на сервер, в группу безопасности которого не входили серверы заданий MapReduce. Поэтому редуктор истекал и убивался. В идеале я хотел бы добавить свои задания в ту же группу безопасности, но я решил просто добавить параметр маркера безопасности URL-адреса перед своим API.

person creoe    schedule 06.05.2013