Wie behebe ich den Fehler „Container killed on request. Exit code is 137" von einem Spark-Auftrag in Amazon EMR?

Lesedauer: 5 Minute

Mein Apache-Spark-Auftrag in Amazon EMR schlägt fehl und ich erhalte die Fehlermeldung „Container killed on request. Exit code is 137“.

Kurzbeschreibung

Wenn einem Container der Speicher ausgeht, stoppt 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

Erhöhen des Treiber- oder Containerspeichers

Um den Container-Speicher des laufenden Clusters oder Einzelauftrags zu erhöhen, verbinde zuerst den Primärknoten des Clusters. Ändere dann die Parameter spark.executor.memory oder spark.driver.memory in der Spark-Konfigurationsdatei spark-defaults.conf.

Laufender 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 erhöhen, füge den Parameter spark.executor.memory oder spark.driver.memory in spark-defaults.conf hinzu oder ändere ihn:

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

Hinweis: Ersetze 10g durch einen Wert, der den verfügbaren Ressourcen und Workload-Anforderungen des Clusters entspricht.

Einzelauftrag

Um den Arbeitsspeicher zu erhöhen, verwende die Option --executor-memory oder --driver-memory, wenn du den folgenden Befehl spark-submit ausführst:

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

Hinweis: Ersetze 10g durch einen Wert, der den verfügbaren Ressourcen und Workload-Anforderungen des Clusters entspricht.

Du kannst set maximizeResourceAllocation auch in der Spark-Konfigurationsklassifizierung auf true (wahr) setzen.

Weitere Spark-Partitionen hinzufügen

Wenn du den Container-Speicher nicht erhöhen kannst, erhöhe die Anzahl der Spark-Partitionen, um die Menge der verarbeiteten Daten und den verwendeten Speicher zu reduzieren.

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

Wenn das Problem während einer umfassenden Transformation auftritt, z. B. bei join oder groupBy, stelle eine Verbindung zum Primärknoten des Clusters her und füge weitere Shuffle-Partitionen hinzu. Der Standardwert ist 200.

Laufender Cluster

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

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

Um Shuffle-Partitionen zur Konfigurationsdatei hinzuzufügen, führe den folgenden Befehl aus:

spark.sql.shuffle.partitions 500

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

Einzelauftrag

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

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

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

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. Um die Anzahl der Executor-Kerne zu reduzieren, stelle zuerst eine Verbindung zum Primärknoten des Clusters her und ändere dann den Parameter für die Executor-Kerne.

Laufender Cluster

Öffne 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 zu reduzieren:

spark.executor.cores  1

Hinweis: Ersetze 1 durch die Mindestanzahl von Executor-Kernen, die du benötigst.

Einzelauftrag

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

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

Erhöhen der Instance-Größe

Wenn dem Betriebssystem der Speicher ausgeht, stoppt das Betriebssystem oom_reaper möglicherweise auch die YARN-Container. Wenn oom_reaper den Fehler verursacht hat, verwende eine größere Amazon Elastic Compute Cloud (Amazon EC2)-Instance mit mehr RAM. Um sicherzustellen, dass YARN-Container nicht den gesamten RAM verwenden, verringere 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 hat. Verwende zunächst die YARN-Resource-Manger-Benutzeroberfläche oder die Protokolle, um den Kern- oder Aufgabenknoten zu finden, auf dem der gestoppte YARN-Container ausgeführt wurde. Überprüfe dann die Amazon-EMR-Instance-Zustandsprotokolle auf dem Knoten vor und nach dem Stoppen des Containers.

Im folgenden Beispiel stoppt der Kernel den Prozess, der die ID 36787 hat und 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 Festplattenauslastung und Leistungsabfall des Knotens prüfen

Wenn die oben genannten Optionen zur Problembehandlung das Problem nicht lösen, verwende das df-h-Flag in den Instance-Zustandsprotokollen, um die Festplattenauslastung und den Leistungsabfall des Knotens zu überprüfen. Überprüfe auch den Zustand der Knoten auf dem AWS-Servicestatus-Dashboard.