Wie behebe ich „Container killed on request. Exit code is 137“-Fehler in Spark auf Amazon EMR?

Kurzbeschreibung

Wenn einem Container (Spark-Executor) der Speicher ausgeht, beendet YARN den Container automatisch und du erhältst möglicherweise die folgende Fehlermeldung:
„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“

Lösung

Erweitere den Treiber- oder den Executor-Speicher

Um den Container-Speicher zu erweitern, verbinde zuerst den Primärknoten des Clusters und ändere dann die Parameter spark.executor.memory oder spark.driver.memory in der Spark-Konfigurationsdatei (spark-defaults.conf).

Ausgeführte Cluster

Führe den folgenden Befehl aus, um spark-defaults.conf zu öffnen:

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

Um den Container-Speicher zu erweitern, füge die folgenden Parameter in spark-defaults.conf hinzu oder ändere sie:

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

Hinweis: Ersetze 10g durch Speicherwerte, die den verfügbaren Ressourcen und Workload-Anforderungen deines Clusters entsprechen.

Einzelner Auftrag

Verwende die Option --executor-memory oder --driver-memory, um den Speicher zu erweitern, wenn du spark-submit ausführst.

Beispiel:

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

Hinweis: Ersetze 10g durch entsprechende Speicherwerte, die den verfügbaren Ressourcen und Workload-Anforderungen deines Clusters entsprechen.

Weitere Spark-Partitionen hinzufügen

Wenn du den Container-Speicher nicht erweitern kannst (z. B. bei der Verwendung von maximizeResourceAllocation auf dem Knoten), erhöhe die Anzahl der Spark-Partitionen. Das reduziert die Datenmenge, die von einer einzelnen Spark-Aufgabe verarbeitet wird, und den Gesamtspeicher, der von einem einzelnen Executor verwendet wird.

Um weitere Spark-Partitionen hinzuzufügen, verbinde zuerst den Primärknoten des Clusters und führe dann die folgenden Befehle in der Spark-Shell aus:

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

Hinweis: Ersetze 500 durch die Anzahl der Partitionen, die deiner Datengröße entspricht.

Erhöhen der Anzahl der Shuffle-Partitionen

Tritt der Fehler während einer umfassenden Transformation auf, beispielsweise join oder groupBy, stelle zuerst eine Verbindung zum Primärknoten des Clusters her und füge dann weitere Shuffle-Partitionen hinzu. Der Standardwert ist 200.

Ausgeführte Cluster

Führe den folgenden Befehl aus, um spark-defaults.conf zu öffnen:

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

Aktualisiere die Shuffle-Partitionen in der Konfigurationsdatei:

spark.sql.shuffle.partitions 500

Hinweis: Ersetze 500 durch die Anzahl der Partitionen, die deiner Datengröße entspricht.

Einzelner Auftrag

Verwende die Option --conf spark.sql.shuffle.partitions, um weitere Shuffle-Partitionen hinzuzufügen, wenn du spark-submit ausführst.

Beispiel:

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

Reduzieren der Anzahl der Executor-Kerne

Wenn du die Anzahl der Executor-Kerne reduzierst, reduziere auch die maximale Anzahl von Aufgaben, die der Executor gleichzeitig verarbeitet. Dies reduziert die Menge an Speicher, die der Container verwendet.

Ausgeführte Cluster

Stelle zuerst eine Verbindung zum Primärknoten des Clusters her und öffne dann die Datei spark-defaults.conf auf dem Primärknoten:

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

Ändere den Parameter spark.executor.cores, um die Anzahl der Executor-Kerne festzulegen:

spark.executor.cores  1

Hinweis: Ersetze 1 durch die Anzahl der Executor-Kerne, die du für deinen Anwendungsfall benötigst.

Einzelner Auftrag

Verwende die Option --executor-cores, um die Anzahl der Executor-Kerne zu reduzieren, wenn du spark-submit ausführst.

Beispiel:

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

Erhöhen der Instance-Größe

Wenn dem Betriebssystem der Speicher ausgeht, beendet oom_reaper des Betriebssystems möglicherweise auch die YARN-Container. Wenn dies den Fehler verursacht, verwende eine größere Instance mit mehr RAM. Um sicherzustellen, dass YARN-Container nicht den gesamten Arbeitsspeicher von Amazon Elastic Compute Cloud (Amazon EC2) verbrauchen, senke yarn.nodemanager.resource.memory-mb.

Überprüfe die Amazon EMR-Instance-Protokolle für die dmesg-Befehlsausgabe, um festzustellen, ob oom_reaper den Fehler verursacht. Verwende zunächst die YARN Resource Manger-Benutzeroberfläche oder die Protokolle, um den Kern- oder Aufgabenknoten zu finden, auf dem der beendete YARN-Container ausgeführt wurde. Überprüfe dann die Amazon EMR-Instance-Statusprotokolle auf diesem Knoten vor und nach dem Beenden des Containers, um festzustellen, ob oom_reaper den Prozess beendet hat.

Im folgenden Beispiel beendet der Kernel (OOM-Killer von Linux) den Prozess mit der ID 36787, der YARN container_165487060318_0001_01_000244 entspricht:

# 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

Auf Datenträgerverwendung und Leistungsminderung des Knotens prüfen

Wenn die oben genannten Optionen zur Problembehandlung den Fehler nicht beheben, überprüfe die Datenträgerverwendung und Leistungsminderung des Knotens. Verwende das df-h-Flag in den Instance-Statusprotokollen, um die Datenträgerverwendung von Clustern und Knoten zu überprüfen. Überprüfe auch den Zustand der Knoten auf dem Amazon-Servicestatus-Dashboard.

Ähnliche Informationen

Wie behebe ich den Fehler „Container killed by YARN for exceeding memory limits“ in Spark auf Amazon EMR?

Wie kann ich Stufenfehler in Spark-Aufträgen auf Amazon EMR beheben?