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

4 minuti di lettura
0

Il mio processo Apache Spark su Amazon EMR ha esito negativo con un errore di fase "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 descrizione

Quando un container (esecutore Spark) esaurisce la memoria, YARN lo interrompe automaticamente. Ciò produce l'errore "Container killed on request. Exit code is 137". Questi errori possono verificarsi in diverse fasi del processo, in trasformazioni sia strette che ampie. I contenitori YARN possono anche essere interrotti dal sistema operativo oom_reaper quando la memoria del sistema operativo sta per esaurirsi, provocando l'errore "Container killed on request. Exit code is 137".

Risoluzione

Utilizza uno o più dei metodi seguenti per risolvere gli errori di fase "Exit status: 137".

Aumenta la memoria del driver o dell'esecutore

Aumenta la memoria del container regolando i parametri spark.executor.memory o spark.driver.memory (a seconda del container che ha causato l'errore).

Su un cluster in esecuzione:

Modifica il valore spark-defaults.conf sul nodo primario. Esempio:

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

Per un singolo processo:

Usa l'opzione --executor-memory o --driver-memory per aumentare la memoria quando esegui il comando spark-submit. Esempio:

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

Aggiungi altre partizioni Spark

Se non riesci ad aumentare la memoria del container (ad esempio, se stai usando maximizeResourceAllocation sul nodo), aumenta il numero di partizioni Spark. In questo modo si ridurrà la quantità di dati elaborati da una singola attività Spark e si ridurrà la memoria complessiva utilizzata da un singolo esecutore. Usa il seguente codice Scala per aggiungere altre partizioni Spark:

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

Aumenta il numero di partizioni casuali

Se l'errore si verifica durante una trasformazione ampia (ad esempio join o groupBy), aggiungi altre partizioni casuali. Il valore predefinito è 200.

Su un cluster in esecuzione:

Modifica il valore spark-defaults.conf sul nodo primario. Esempio:

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

Per un singolo processo:

Usa l'opzione**--conf spark.sql.shuffle.partitions** per aggiungere altre partizioni casuali quando esegui il comando spark-submit. Esempio:

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

Riduci il numero di core dell'esecutore

La riduzione del numero di core dell'esecutore riduce il numero massimo di attività che l'esecutore elabora contemporaneamente. In questo modo si ridurrà la quantità di memoria utilizzata dal container.

Su un cluster in esecuzione:

Modifica il valore spark-defaults.conf sul nodo primario. Esempio:

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

Per un singolo processo:

Usa l'opzione --executor-cores per ridurre il numero di core dell'esecutore quando esegui il comando spark-submit. Esempio:

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

Aumenta le dimensioni dell'istanza

I container YARN possono anche essere interrotti dal sistema operativo oom_reaper quando la memoria del sistema operativo sta per esaurirsi. Se questo errore si verifica a causa di oom_reaper, usa un'istanza più grande con più RAM. Puoi anche abbassare il valore yarn.nodemanager.resource.memory-mb per evitare che i container YARN utilizzino tutta la RAM di Amazon EC2.

Puoi rilevare se l'errore è dovuto a oom_reaper esaminando i log delle tue istanze Amazon EMR per l'output del comando dmesg. Inizia trovando il core o il nodo dell'attività in cui era in esecuzione il container YARN interrotto. Puoi trovare queste informazioni utilizzando i log o l'interfaccia utente di YARN Resource Manager. Quindi, controlla i log di stato dell'istanza Amazon EMR su questo nodo prima e dopo l'interruzione del container per vedere cosa ha interrotto il processo.

Nell'esempio seguente, il processo con ID 36787 corrispondente al container YARN_165487060318_0001_01_000244 è stato interrotto dal kernel (il killer OOM di 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

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?

AWS UFFICIALE
AWS UFFICIALEAggiornata 2 anni fa