Amazon Elastic MapReduce - SIGTERM

Tengo un trabajo de transmisión EMR (Python) que normalmente funciona bien (por ejemplo, 10 máquinas que procesan 200 entradas). Sin embargo, cuando lo funciono contra grandes conjuntos de datos (12 máquinas de procesamiento de un total de 6000 entradas, en alrededor de 20 segundos por entrada), después de 2,5 horas de crujido consigo el siguiente error: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)

Si estoy leyendo esto correctamente, el subproceso falló con el código 143 porque alguien envió una señal SIGTERM al trabajo de transmisión.

¿Es correcto mi entendimiento? De ser así: ¿Cuándo enviaría la infraestructura EMR un SIGTERM?

Fuente

2012-08-15 slavi

¿Ha comprobado las métricas de CloudWatch para ver si está alcanzando algún tipo de límite de IO? Desde mi experiencia, una vez que alcanzas el límite de IO, comienzan a suceder cosas extrañas. No sé qué tipo de instancia estás usando para tus nodos de datos, pero te sugiero actualizar a algo con un rendimiento de E/S más rápido cuando se ejecutan trabajos más grandes. – Edenbauer

El problema es que cada tarea está unida a CPU, con E/S raras y esporádicas. Lo que hace es que carga un archivo desde S3, y luego durante unos 20 segundos realiza un gran procesamiento de CPU. Cada 5 segundos almacena otro archivo (intermedio) en S3. Utiliza algunas bibliotecas externas (lxml, scikit-learn), y pensé que tal vez una de ellas me estaba fallando (¿por un aumento en el consumo de memoria?), Y que la infraestructura EMR estaba enviando un SIGTERM. Para verificar eso, intento comprender los casos/escenarios en que EMR puede SIGTERM un proceso. – slavi

Descubrí lo que estaba sucediendo, así que aquí hay información si alguien más experimenta problemas similares.

La clave para mí fue ver los registros "jobtracker". Estos viven en los registros de su tarea/carpeta en S3, en:

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

Había varias líneas de los siguientes tipos:

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!

Así que mi código se agote el tiempo, y se está matando (se iba más allá del tiempo de espera de la tarea de 10 minutos). 10 minutos No estaba haciendo ningún I/Os, que ciertamente no se esperaba (normalmente haría una E/S cada 20 segundos).

entonces descubrí este artículo:.

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

"En uno de nuestros proyectos de ciencia, tenemos algunos trabajos de Hadoop Streaming que se ejecutan sobre el rubí y dependen de libxml a analizar documentos Esto crea una perfecta tormenta de maldad: la web está llena de html realmente malo y libxml ocasionalmente entra en bucles infinitos o segmentaciones absolutas. En algunos documentos, siempre segfaults ".

Lo clavó. Debo experimentar una de estas situaciones de "libxml entrando en un bucle infinito" (estoy usando libxml en gran medida, solo con Python, no con Ruby).

El último paso para mí fue activar el modo de omisión (instrucciones aquí: Setting hadoop parameters with boto?).

Fuente

2012-08-22 11:21:26 slavi

Gracias por publicar la respuesta a su propio problema. Esto me ayudó a depurar uno similar que estoy teniendo. –

Ídem, estaba ejecutando un trabajo de hadoop de mrjob que falló sin otro resultado que el publicado en la pregunta original. Este fue el único registro útil que me ayudó a encontrar la causa raíz (el contenedor mapeador hadoop2 se estaba quedando sin memoria). – jonson

Me encontré con esta salida de Amazon EMR ("subproceso que falló con el código 143"). Mi trabajo de transmisión utilizaba el curl de PHP para enviar datos a un servidor que no tenía los servidores de tareas de MapReduce como parte de su grupo de seguridad. Por lo tanto, el reductor estaba caducando y siendo matado. Idealmente, me gustaría agregar mis trabajos al mismo grupo de seguridad, pero opté por simplemente agregar un token de seguridad de URL param frente a mi API.

Fuente

2013-05-06 20:48:58 creoe

Amazon Elastic MapReduce - SIGTERM

Respuesta

Cuestiones relacionadas