Come posso risolvere gli errori "Container killed on request. Exit code is 137" in Spark su Amazon EMR?
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 gli errori di fase nei processi Spark in Amazon EMR?
Video correlati
Contenuto pertinente
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 mesi fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa