Como posso resolver erros "Container killed on request. Exit code is 137" do Spark no Amazon EMR?

4 minuto de leitura
0

Meu trabalho do Apache Spark no Amazon EMR falha com uma falha de estágio "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 descrição

Quando um contêiner (executor do Spark) fica sem memória, o YARN o elimina automaticamente. Isso causa o erro “Container killed on request. Exit code is 137”. Esses erros podem ocorrer em diferentes estágios do trabalho, tanto em transformações estreitas quanto em amplas. Contêineres YARN também podem ser eliminados pelo oom_reaper do sistema operacional quando este está ficando sem memória, causando o erro “Container killed on request. Exit code is 137”.

Resolução

Use um ou mais dos seguintes métodos para resolver falhas de estágio “Exit status: 137”.

Aumentar a memória do driver ou do executor

Aumente a memória do contêiner ajustando os parâmetros spark.executor.memory ou spark.driver.memory (dependendo de qual contêiner causou o erro).

Em um cluster em execução:

Modifique spark-defaults.conf no nó principal. Exemplo:

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

Para um único trabalho:

Use a opção --executor-memory ou --driver-memory para aumentar a memória ao executar spark-submit. Exemplo:

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

Adicione mais partições do Spark

Se você não conseguir aumentar a memória do contêiner (por exemplo, se estiver usando maximizeResourceAllocation no nó), aumente o número de partições do Spark. Isso diminui a quantidade de dados processados por uma única tarefa do Spark e reduz a memória geral usada por um único executor. Use o seguinte código Scala para adicionar mais partições do Spark:

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

Aumentar o número de partições aleatórias

Se o erro ocorrer durante uma transformação ampla (por exemplo, join ou groupBy), adicione mais partições aleatórias. O valor padrão é 200.

Em um cluster em execução:

Modifique spark-defaults.conf no nó principal. Exemplo:

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

Para um único trabalho:

Use a opção --conf spark.sql.shuffle.partitions para adicionar mais partições aleatórias ao executar spark-submit. Exemplo:

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

Reduzir o número de núcleos do executor

Reduzir o número de núcleos do executor reduz o número máximo de tarefas que o executor processa simultaneamente. Isso reduz a quantidade de memória usada pelo contêiner.

Em um cluster em execução:

Modifique spark-defaults.conf no nó principal. Exemplo:

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

Para um único trabalho:

Use a opção --executor-cores para reduzir o número de núcleos executores ao executar spark-submit. Exemplo:

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

Aumentar o tamanho da instância

Contêineres YARN também podem ser eliminados pelo oom_reaper do sistema operacional quando este está ficando sem memória. Se esse erro ocorrer por causa de oom_reaper, use uma instância maior com mais RAM. Você também pode reduzir yarn.nodemanager.resource.memory-mb para evitar que os contêineres YARN usem toda a memória RAM do Amazon EC2.

Você pode detectar se o erro é causado por oom_reaper, analisando os logs da instância do Amazon EMR para verificar a saída do comando dmesg. Comece encontrando o núcleo ou o nó de tarefa em que o contêiner YARN eliminado estava em execução. Você pode encontrar essas informações usando os logs ou a interface de usuário do Gerenciador de recursos do YARN. Em seguida, verifique os logs de Estado da instância do Amazon EMR nesse nó antes e depois da eliminação do contêiner para ver o que interrompeu o processo.

No exemplo a seguir, o processo com ID 36787 correspondente ao contêiner YARN_165487060318_0001_01_000244 foi eliminado pelo kernel (o agente de eliminação OOM do Linux):

# 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

Informações relacionadas

Como resolvo o erro “Contêiner eliminado pelo YARN por exceder os limites de memória” do Spark no Amazon EMR?

Como posso solucionar falhas de estágio em trabalhos do Spark no Amazon EMR?

AWS OFICIAL
AWS OFICIALAtualizada há 2 anos