Wie behebe ich eine Fehlermeldung "ExecutorLostFailure: Slave lost" in Spark auf Amazon EMR?

Lösung

Wenn eine Spark-Aufgabe fehlschlägt, weil ein Knoten beendet wurde oder nicht mehr verfügbar ist, erhältst du möglicherweise die folgende Fehlermeldung:

"Most recent failure: Lost task 1209.0 in stage 4.0 (TID 31219, ip-###-###-##-###.compute.internal, executor 115): ExecutorLostFailure (executor 115 exited caused by one of the running tasks) Reason: Slave lost"

Im Folgenden sind einige der Gründe aufgeführt, warum dir diese Fehlermeldung angezeigt wird.

Hohe Festplattenauslastung aufgrund eines fehlerhaften Knotens

In Apache Hadoop überprüft NodeManager regelmäßig die Volumes von Amazon Elastic Block Store (Amazon EBS), die an die Knoten des Clusters angeschlossen sind. Wenn die Festplattenauslastung auf einem Knoten mit einem Volume höher ist als die YARN-Eigenschaft yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage, stuft NodeManager den Knoten als fehlerhaft ein. Daraufhin fährt ResourceManager alle Container auf diesem Knoten herunter und plant keine neuen Container. Weitere Informationen findest du unter NodeManager auf der Apache-Hadoop-Website.

Nachdem ResourceManager mehrere Executors aufgrund fehlerhafter Knoten heruntergefahren hat, bricht die Anwendung ab und gibt folgende Fehlermeldung aus: ExecutorLostFailure fehl: Slave lost. Um zu überprüfen, ob ein Knoten fehlerhaft ist, überprüfe das NodeManager-Protokoll oder das Instance-Controller-Protokoll. Der Speicherort des NodeManager-Protokolls ist in der Variable YARN_LOG_DIR in yarn-env.sh definiert. Das Instance-Controller-Protokoll wird unter /emr/instance-controller/log/instance-controller.log auf dem Primärknoten gespeichert. Die Instance-Controller-Protokolle bieten eine aggregierte Ansicht aller Knoten des Clusters.

Ein fehlerhafter Knoten enthält einen Protokolleintrag, der mit dem folgenden Eintrag vergleichbar ist:

2019-10-04 11:09:37,163 INFO Poller: InstanceJointStatusMap contains 40 entries (R:40):  i-006ba######  1829s R   1817s ig-3B ip-###-##-##-### I:    7s Y:U    11s c: 0 am:    0 H:R  0.0%Yarn unhealthy Reason : 1/1 local-dirs are bad: /mnt/yarn; 1/1 log-dirs are bad: /var/log/hadoop-yarn/containers
  i-00979######  1828s R   1817s ig-3B ip-###-##-##-### I:    7s Y:R     9s c: 3 am: 2048 H:R  0.0%
  i-016c4######  1834s R   1817s ig-3B ip-###-##-##-### I:   13s Y:R    14s c: 3 am: 2048 H:R  0.0%
  i-01be3######  1832s R   1817s ig-3B ip-###-##-##-### I:   10s Y:U    12s c: 0 am:    0 H:R  0.0%Yarn unhealthy Reason : 1/1 local-dirs are bad: /mnt/yarn; 1/1 log-dirs are bad: /var/log/hadoop-yarn/containers

Erhöhe die Größe der EBS-Volumes, die an die Kern- und Aufgabenknoten angeschlossen sind, um dieses Problem zu lösen. Oder lösche ungenutzte Daten aus dem Hadoop Distributed File System (HDFS).

Spot-Instanzen

Wenn du Spot Instances der Amazon Elastic Compute Cloud (EC2) für Amazon-EMR-Clusterknoten verwendest und eine der Instances beendet wird, erhältst du möglicherweise die folgende Fehlermeldung: ExecutorLostFailure: Slave lost. Spot Instances können aus den folgenden Gründen beendet werden:

• Der Spot-Instance-Preis liegt über deinem Höchstpreis.
• Deine verfügbaren EC2-Instances decken nicht der Nachfrage nach Spot Instances.

Weitere Informationen findest du unterSpot Instance-Unterbrechungen.

Verwende On-Demand-Instances, um dieses Problem zu beheben. Oder, wenn du Amazon-EMR-Release-Version 5.11.0 oder früher verwendest, führe ein Upgrade auf die neueste Version durch.

Amazon EC2 Auto Scaling-Richtlinien

Bei häufigen Auto-Scaling-Ereignissen erhält ein neuer Knoten möglicherweise eine IP-Adresse, die ein früherer Knoten verwendet hat. Wenn eine Spark-Anwendung während eines Abskalierungsereignisses ausgeführt wird, fügt Spark den stillgelegten Knoten zur Ablehnungsliste hinzu, sodass kein Executor auf diesem Knoten gestartet wird. Wenn ein weiteres Aufskalierungsereignis eintritt und der neue Knoten dieselbe IP-Adresse wie der stillgelegte Knoten erhält, betrachtet YARN den neuen Knoten als gültig. YARN versucht, Executors auf dem neuen Knoten zu planen. Da der Knoten weiterhin auf der Ablehnungsliste von Spark steht, schlägt der Start von Executors fehl. Sobald die Höchstzahl der Fehlschläge erreicht ist, bricht die Spark-Anwendung ab und gibt die folgende Fehlermeldung aus: ExecutorLostFailure: Slave lost.

Gehe wie folgt vor, um dieses Problem zu beheben:

• Verwende weniger aggressive Regeln in den Skalierungsrichtlinien. Weitere Informationen findest du unter Grundlegendes zu Auto Scaling-Regeln.
• Erhöhe die Anzahl der verfügbaren IP-Adressen im Subnetz. Weitere Informationen findest du unter Subnetz-CIDR-Blöcke.

Um einen Knoten aus der Ablehnungsliste von Spark zu entfernen, verringere die Timeout-Eigenschaften von Spark und YARN. Führe die folgenden Schritte aus:

1. Füge der Datei /etc/spark/conf/spark-defaults.conf den folgenden Parameter hinzu:

   spark.blacklist.decommissioning.timeout 600s

   Hinweis: Dadurch wird die Zeit reduziert, in der ein Knoten im Außerbetriebnahme-Status auf der Ablehnungsliste verbleibt. Die Standardeinstellung ist eine Stunde. Weitere Informationen findest du unter Konfiguration des Verhaltens bei der Außerbetriebnahme von Knoten.
2. Ändere die folgende YARN-Eigenschaft in /etc/hadoop/conf/yarn-site.xml:

   yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs 600

   Hinweis: Diese Eigenschaft gibt an, wie lange gewartet werden muss, bis die Ausführung von Containern und Anwendungen abgeschlossen ist, bevor ein Knoten zur Außerbetriebnahme in den Status „Stillgelegt“ übergeht. Die Standardeinstellung ist 3600 Sekunden.

Weitere Informationen findest du unter Spark-Verbesserungen für Elastizität und Resilienz in Amazon EMR.

Ähnliche Informationen

Konfiguration der Amazon-EMR-Cluster-Instance-Typen und bewährte Methoden für Spot Instances

Wie kann ich Stufenfehler in Spark-Jobs auf Amazon EMR beheben?