Wie behebe ich „Container wurde auf Anfrage gelöscht. Ist der Exit-Code 137“-Fehler in Spark auf Amazon EMR?

Lesedauer: 4 Minute

Mein Apache Spark-Job auf Amazon EMR schlägt mit einem Fehler in der Phase „Container auf Anfrage beendet“ fehl: Verursacht durch: org.apache.spark.SparkException: Der Job wurde aufgrund eines Phasenfehlers abgebrochen: Aufgabe 2 in Phase 3.0 ist viermal fehlgeschlagen, letzter Fehler: Aufgabe 2.3 in Phase 3.0 verloren (TID 23, ip-xxx-xxx-xx-xxx.compute.internal, executor 4): ExecutorLostFailure (Executor 4 wurde aufgrund einer der laufenden Aufgaben beendet) Grund: Als ausgefallen markierter Container: container_1516900607498_6585_01_000008 auf dem Host: ip-xxx-xxx-xx-xxx.compute.internal. Ausgangsstatus: 137. Diagnosen: Container auf Anfrage beendet. Der Exit-Code ist 137

Kurzbeschreibung

Wenn einem Container (Spark-Executor) der Speicher ausgeht, beendet YARN ihn automatisch. Dadurch wird der Fehler „Container auf Anfrage beendet. Der Exit-Code lautet 137“ verursacht. Diese Fehler können in verschiedenen Arbeitsphasen auftreten, sowohl bei engen als auch bei breiten Transformationen. YARN-Container können auch vom Betriebssystem oom_reaper beendet werden, wenn dem Betriebssystem der Speicher ausgeht, wodurch der Fehler „Container auf Anfrage beendet. Der Exit-Code lautet 137“ verursacht.

Behebung

Verwenden Sie eine oder mehrere der folgenden Methoden, um die Phasenfehler „Exit-Status“: 137“ zu beheben.

Erhöhen Sie den Treiber- oder den Executor-Speicher

Erhöhen Sie den Containerspeicher, indem Sie die Parameter spark.executor.memory oder spark.driver.memory anpassen (je nachdem, welcher Container den Fehler verursacht hat).

Auf einem laufenden Cluster:

Ändern Sie spark-defaults.conf auf dem Master-Knoten. Beispiel:

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

Für einen einzelnen Job:

Verwenden Sie die Option --executor-memory oder --driver-memory, um den Arbeitsspeicher zu erhöhen, wenn Sie spark-submit ausführen. Beispiel:

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

Weitere Spark-Partitionen hinzufügen

Wenn Sie den Container-Speicher nicht erhöhen können (z. B. wenn Sie maximizeResourceAllocation auf dem Knoten verwenden), erhöhen Sie die Anzahl der Spark-Partitionen. Dadurch wird die Datenmenge reduziert, die von einer einzelnen Spark-Aufgabe verarbeitet wird, und das reduziert den Gesamtspeicher, der von einem einzelnen Executor verwendet wird. Verwenden Sie den folgenden Scala-Code, um weitere Spark-Partitionen hinzuzufügen:

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

Erhöhen Sie die Anzahl der Shuffle-Partitionen

Wenn der Fehler während einer umfassenden Transformation (z. B. join oder groupBy) auftritt, fügen Sie weitere Shuffle-Partitionen hinzu. Der Standardwert ist 200 %.

Auf einem laufenden Cluster:

Ändern Sie spark-defaults.conf auf dem Master-Knoten. Beispiel:

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

Für einen einzelnen Job:

Verwenden Sie die Option**--conf spark.sql.shuffle.partitions**, um weitere Shuffle-Partitionen hinzuzufügen, wenn Sie spark-submit ausführen. Beispiel:

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

Reduzieren Sie die Anzahl der Executor-Kerne

Durch die Reduzierung der Anzahl der Executor-Cores wird die maximale Anzahl von Aufgaben reduziert, die der Executor gleichzeitig verarbeitet. Dadurch wird die Menge an Speicher reduziert, die der Container verwendet.

Auf einem laufenden Cluster:

Ändern Sie spark-defaults.conf auf dem Master-Knoten. Beispiel:

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

Für einen einzelnen Job:

Verwenden Sie die Option --executor-cores, um die Anzahl der Executor-Kerne zu reduzieren, wenn Sie spark-submit ausführen. Beispiel:

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

Erhöhen der Instance-Größe

YARN-Container können auch vom Betriebssystem oom_reaper beendet werden, wenn dem Betriebssystem der Speicher ausgeht. Wenn dieser Fehler aufgrund von oom_reaper auftritt, verwenden Sie eine größere Instance mit mehr RAM. Sie können auch yarn.nodemanager.resource.memory-mb herabsetzen, um zu verhindern, dass YARN-Container den gesamten RAM von Amazon EC2 verbrauchen.

Sie können feststellen, ob der Fehler auf oom_reaper zurückzuführen ist, indem Sie Ihre Amazon EMR-Instance-Protokolle auf die Befehlsausgabe dmesg überprüfen. Suchen Sie zunächst den Kern- oder Taskknoten, auf dem der beendete YARN-Container ausgeführt wurde. Sie können diese Informationen mithilfe der YARN Resource Manager-Benutzeroberfläche oder der Protokolle finden. Überprüfen Sie dann die Amazon EMR-Instance-Statusprotokolle auf diesem Knoten vor und nach dem Beenden des Containers, um zu sehen, was den Prozess beendet hat.

Im folgenden Beispiel wurde der Prozess mit der ID 36787, die dem YARN-Container_165487060318_0001_01_000244 entspricht, vom Kernel (OOM-Killer von Linux) beendet:

# 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