2011-09-05 12 views
6

. Hace unos días me he estado dando vueltas en la cabeza y espero que alguien tenga alguna idea.Fallo en la tarea de transmisión de Hadoop: salida del proceso de tarea con un estado distinto de cero de

He escrito una reducción de mapa de transmisión de trabajo en perl que es propenso a tener una o dos tareas de reducción que toman un tiempo extremadamente largo para ejecutar. Esto se debe a una asimetría natural en los datos: algunas de las teclas de reducción tienen más de un millón de filas, donde la mayoría tiene solo unas pocas docenas.

He tenido problemas con tareas largas antes, y he estado incrementando los contadores en todas partes para asegurarme de que la reducción del mapa no los agote. Pero ahora están fallando con un mensaje de error que no había visto antes:

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

Este no es el mensaje de error de tiempo de espera estándar, pero el código de error 137 = 128 + 9 sugiere que mi guión reductor recibió una matanza - 9 de Hadoop. El registro de TaskTracker contiene lo siguiente:

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) 

He estado buscando alrededor de los foros, y parece que las advertencias se encuentran comúnmente en los trabajos que se ejecutan sin errores, y por lo general pueden ser ignorados. El error hace que parezca que el reductor perdió contacto con la salida del mapa, pero no puedo entender por qué. ¿Alguien tiene alguna idea?

Aquí hay un hecho potencialmente relevante: estas tareas largas hacían que mi trabajo tomara días en los que tardaría unos minutos. Desde que puedo vivir sin la salida de una o dos teclas, he tratado de poner en práctica un tiempo de espera de diez minutos en el mi reductor de la siguiente manera:

código
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; 
    }; 

Este tiempo de espera funciona como un encanto cuando pruebo la secuencia de comandos de forma local, pero el extraños errores de mapreduce comenzaron después de que lo introduje. Sin embargo, las fallas parecen ocurrir mucho después del primer tiempo de espera, así que no estoy seguro de si está relacionado.

¡Gracias de antemano por cualquier ayuda!

+0

Olvidé mencionar, estoy usando hadoop 0.20.2. –

Respuesta

10

dos posibilidades vienen a la mente:

  1. uso de memoria RAM, si una tareas utiliza demasiada memoria RAM del sistema operativo puede acabar con él (después del intercambio horrible, etc).
  2. ¿Está utilizando alguna biblioteca no reentrante? Tal vez el temporizador se active en un momento inoportuno en una llamada a la biblioteca.
+0

¿Podrías pormenorizar el segundo ('non-reentrant')? – Alcott

+0

Primero verificaría la primera sugerencia (el asesino OOM de Linux), porque un código de retorno de 137 es una especie de firma (128 + 9 para SIG_KILL). Es bastante directo determinar si usted está afligido por esta condición: egrep -i 'proceso inactivo'/var/log/messages, también desarrollado en esta respuesta: http://stackoverflow.com/a/624868/366749 –

+0

Lo siento, me perdí este comentario. Algunas bibliotecas (tuvimos problemas con las bibliotecas de autenticación de Quest hace un par de años) no son compatibles con múltiples subprocesos y si las tareas del kernel cambian mientras están activas, "suceden cosas malas". – cftarnas

5

El código de salida 137 es un signo típico del infame asesino de OOM. Puede comprobar fácilmente usando dmesg comandos para mensajes como este:

[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 

puedes fácilmente si OOM está habilitado:

$ cat /proc/sys/vm/overcommit_memory 
0 

Básicamente asesino OOM intenta matar el proceso que se come más grande parte de la memoria. Y usted probably don't want to disable it:

El OOM killer puede desactivarse por completo con el siguiente comando. Esto no se recomienda para entornos de producción, porque si se presenta una condición de memoria sin memoria, podría haber un comportamiento inesperado según los recursos del sistema disponibles y la configuración .Este comportamiento inesperado podría ser cualquier cosa, desde un pánico de kernel hasta un cuelgue dependiendo de los recursos disponibles para el kernel en el momento de la condición OOM.

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

La misma situación puede ocurrir si se utiliza, por ejemplo, cgroups para limitar la memoria. Cuando el proceso excede el límite dado, se elimina sin previo aviso.

0

Recibí este error. Matar un día y descubrió que era un bucle infinito en algún lugar del código.

Cuestiones relacionadas