Come posso risolvere gli errori "Container killed on request. Exit code is 137" di Spark in Amazon EMR?

Breve descrizione

Quando un container (esecutore Spark) esaurisce la memoria, YARN interrompe automaticamente il container e potresti ricevere il seguente errore:
"Container killed on request" stage failure: 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-###-###-##-###.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-###-###-##-###.compute.internal. Exit status: 137. Diagnostics: Container killed on request. Exit code is 137"

Risoluzione

Aumenta la memoria del driver o dell'esecutore

Per aumentare la memoria del container, prima connettiti al nodo primario del cluster, quindi modifica i parametri spark.executor.memory o spark.driver.memory nel file di configurazione di Spark (spark-defaults.conf).

Cluster in esecuzione

Per aprire spark-defaults.conf, esegui questo comando:

sudo vim /etc/spark/conf/spark-defaults.conf

Per aumentare la memoria del container, aggiungi o modifica i seguenti parametri in spark-defaults.conf:

spark.executor.memory 10g
spark.driver.memory 10g

Nota: sostituisci 10g con valori di memoria in base alle risorse disponibili del tuo cluster e ai requisiti del carico di lavoro.

Processo singolo

Quando esegui spark-submit, utilizza l'opzione --executor-memory o --driver-memory per aumentare la memoria.

Esempio:

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

Nota: sostituisci 10g con valori di memoria appropriati in base alle risorse disponibili del tuo cluster e ai requisiti del carico di lavoro.

Aggiungi altre partizioni Spark

Se non riesci ad aumentare la memoria del container, ad esempio utilizzi MaximizeResourceAllocation sul nodo, aumenta il numero di partizioni Spark. Ciò riduce la quantità di dati elaborati da una singola attività Spark e la memoria complessiva utilizzata da un singolo esecutore.

Per aggiungere altre partizioni Spark, prima connettiti al nodo primario del cluster, quindi esegui questi comandi nella shell Spark:

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

Nota: sostituisci 500 con il numero di partizioni che si adattano alle dimensioni dei tuoi dati.

Aumenta il numero di partizioni shuffle

Se l'errore si verifica durante una grande trasformazione, ad esempio join o groupBy, prima connettiti al nodo primario del cluster, quindi aggiungi altre partizioni shuffle. Il valore predefinito è 200.

Cluster in esecuzione

Per aprire spark-defaults.conf, esegui questo comando:

sudo vim /etc/spark/conf/spark-defaults.conf

Aggiorna le partizioni shuffle nel file di configurazione:

spark.sql.shuffle.partitions 500

Nota: sostituisci 500 con il numero di partizioni che si adattano alle dimensioni dei tuoi dati.

Processo singolo

Quando esegui spark-submit, utilizza l'opzione**--conf spark.sql.shuffle.partitions** per aggiungere altre partizioni shuffle.

Esempio:

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

Riduci il numero di core dell’esecutore

Quando riduci il numero di core dell'esecutore, riduci anche il numero massimo di attività che l'esecutore elabora contemporaneamente. Ciò riduce la quantità di memoria utilizzata dal container.

Cluster in esecuzione

Prima connettiti al nodo primario del cluster, quindi apri il file spark-defaults.conf nel nodo primario:

sudo vim /etc/spark/conf/spark-defaults.conf

Per impostare il numero di core dell'esecutore, modifica il parametro spark.executor.cores:

spark.executor.cores  1

Nota: sostituisci 1 con il numero di core dell'esecutore necessari per il tuo caso d'uso.

Processo singolo

Utilizza l'opzione --executor-cores per ridurre il numero di core dell’esecutore quando esegui spark-submit.

Esempio:

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

Aumenta le dimensioni dell'istanza

Quando la memoria del sistema operativo si esaurisce, il suo oom_reaper potrebbe anche interrompere i container YARN. Se ciò causa l'errore, utilizza un'istanza più grande con più RAM. Per assicurarti che i container YARN non utilizzino tutta la RAM di Amazon Elastic Compute Cloud (Amazon EC2), riduci yarn.nodemanager.resource.memory-mb.

Esamina l'output del comando dmesg nei log dell'istanza Amazon EMR per stabilire se la causa dell'errore è oom_reaper. Prima di tutto, utilizza l'interfaccia utente o i log di YARM Resource Manager per individuare il nodo principale o il nodo attività in cui è stato eseguito il container YARN interrotto. Quindi controlla i log di stato dell'istanza Amazon EMR su questo nodo prima e dopo l'interruzione del container per stabilire se oom_reaper ha interrotto il processo.

Nell'esempio seguente, il kernel (killer OOM di Linux) interrompe il processo con ID 36787 che corrisponde al container YARN container_165487060318_0001_01_000244:

# hows the kernel lookingdmesg | 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

Verifica l'utilizzo del disco e il degrado del nodo

Se le opzioni di risoluzione precedenti non risolvono l'errore, controlla l'utilizzo del disco e il degrado del nodo. Utilizza il flag df-h all'interno dei log di stato dell'istanza per controllare l'utilizzo del disco del cluster e del nodo. Controlla anche la condizione del nodo nella dashboard Amazon Health.

Informazioni correlate

Come posso risolvere l'errore “Container killed by YARN for exceeding memory limits” in Spark su Amazon EMR?

Come posso risolvere gli errori di fase nei processi Spark in Amazon EMR?