¿Cómo puedo solucionar los errores «Container killed on request. Exit code is 137» en Spark en Amazon EMR?

4 minutos de lectura
0

Mi trabajo de Apache Spark en Amazon EMR falla y se produce un error de etapa «Container killed on request»: Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: Task 2 in stage 3.0 failed 4 times, most recent failure: Lost task 2.3 in stage 3.0 (TID 23, ip-xxx-xxx-xx-xxx.compute.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container marked as failed: container_1516900607498_6585_01_000008 on host: ip-xxx-xxx-xx-xxx.compute.internal. Exit status: 137. Diagnostics: Container killed on request. Exit code is 137

Breve descripción

Cuando un contenedor (ejecutor de Spark) se queda sin memoria, YARN lo cierra automáticamente. Esto provoca el error «Container killed on request. Exit code is 137». Estos errores se pueden producir en diferentes etapas del trabajo, tanto en transformaciones angostas como amplias. El sistema operativo oom_reaper también puede cerrar los contenedores de YARN si se está quedando sin memoria, lo que provocaría el error «Container killed on request. Exit code is 137».

Solución

Utilice uno o varios de los siguientes métodos para solucionar los errores de etapa «Exit status: 137».

Aumento de la memoria del controlador o el ejecutor

Ajuste los parámetros spark.executor.memory o spark.driver.memory (en función del contenedor que haya provocado el error) para aumentar la memoria del contenedor en cuestión.

En un clúster en ejecución:

Modifique spark-defaults.conf en el nodo maestro. Ejemplo:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.executor.memory 10g
spark.driver.memory 10g

Para un solo trabajo:

Use las opciones --executor-memory o --driver-memory para aumentar la memoria cuando ejecute spark-submit. Ejemplo:

spark-submit --executor-memory 10g --driver-memory 10g ...

Agregación de más particiones de Spark

Si no puede aumentar la memoria del contenedor (por ejemplo, si utiliza maximizeResourceAllocation en el nodo), incremente la cantidad de particiones de Spark. De este modo, se reduce la cantidad de datos que cada tarea de Spark procesa y se reduce la memoria total utilizada por un único ejecutor. Use el siguiente código de Scala para agregar más particiones de Spark:

val numPartitions = 500
val newDF = df.repartition(numPartitions)

Aumento del número de particiones de mezcla

Si el error se produce durante una transformación amplia (por ejemplo, join o groupBy), agregue más particiones de mezcla. El valor predeterminado es 200.

En un clúster en ejecución:

Modifique spark-defaults.conf en el nodo maestro. Ejemplo:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.sql.shuffle.partitions 500

Para un solo trabajo:

Utilice la opción --conf spark.sql.shuffle.partitions para agregar más particiones de mezcla cuando ejecute spark-submit. Ejemplo:

spark-submit --conf spark.sql.shuffle.partitions=500 ...

Reducción del número de núcleos ejecutores

La reducción del número de núcleos ejecutores reduce el número máximo de tareas que el ejecutor procesa simultáneamente. De este modo, se reduce la cantidad de memoria que utiliza el contenedor.

En un clúster en ejecución:

Modifique spark-defaults.conf en el nodo maestro. Ejemplo:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.executor.cores  1

Para un solo trabajo:

Use la opción --executor-cores para reducir el número de núcleos ejecutores cuando ejecute spark-submit. Ejemplo:

spark-submit --executor-cores 1 ...

Aumento del tamaño de la instancia

El sistema operativo oom_reaper también puede cerrar los contenedores de YARN si se está quedando sin memoria. Si este error se produce debido a oom_reaper, use una instancia más grande con más RAM. También puede reducir yarn.nodemanager.resource.memory-mb para evitar que los contenedores de YARN consuman toda la RAM de Amazon EC2.

Para detectar si el error se debe a oom_reaper, revise el resultado del comando dmesg en los registros de instancias de Amazon EMR. Empiece por encontrar el nodo principal o de tarea en el que se estaba ejecutando el contenedor de YARN cuando se cerró. Encontrará esta información con los registros o la interfaz de usuario del Administrador de recursos de YARN. A continuación, compruebe los registros de estado de la instancia de Amazon EMR en ese nodo antes y después del cierre del contenedor para ver por qué se ha cerrado el proceso.

En el siguiente ejemplo, el proceso con el ID 36787, que corresponde al contenedor de YARN _165487060318_0001_01_000244, ha sido eliminado por el núcleo, es decir, por el cierre de Linux por falta de memoria (OOM):

# hows the kernel looking
dmesg | tail -n 25

[ 3910.032284] Out of memory: Kill process 36787 (java) score 96 or sacrifice child
[ 3910.043627] Killed process 36787 (java) total-vm:15864568kB, anon-rss:13876204kB, file-rss:0kB, shmem-rss:0kB
[ 3910.748373] oom_reaper: reaped process 36787 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Información relacionada

¿Cómo puedo resolver el error «Container killed by YARN for exceeding memory limits» en Spark en Amazon EMR?

¿Cómo puedo solucionar los errores de fase de los trabajos de Spark en Amazon EMR?

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace 2 años