Como posso resolver erros "Container killed on request. Exit code is 137" do Spark no Amazon EMR?
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 posso solucionar falhas de estágio em trabalhos do Spark no Amazon EMR?
Vídeos relacionados
Conteúdo relevante
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há um ano