Performance-Probleme für Funken auf YARN

Question

Wir versuchen, unseren Funken Cluster auf Garn zu betreiben. Vor allem im Vergleich zum Standalone-Modus treten Performance-Probleme auf.

Wir haben einen Cluster von 5 Knoten mit jeweils 16 GB RAM und 8 Kernen. Wir haben die minimale Containergröße als 3 GB und das Maximum als 14 GB in gain-site.xml konfiguriert. Wenn wir den Job dem Garn-Cluster übergeben, liefern wir die Nummer des Executors = 10, des Executor-Speichers = 14 GB. Nach meinem Verständnis sollten unserem Job 4 Container mit 14 GB zugewiesen werden. Aber die Funke UI zeigt nur 3 Container von je 7,2 GB.

Wir können die Containernummer und die zugewiesenen Ressourcen nicht sicherstellen. Dies führt zu einer nachteiligen Leistung im Vergleich zum Standalone-Modus.

Können Sie einen Hinweis darauf geben, wie Sie die Garnleistung optimieren können?

Dies ist der Befehl, den ich für die Einreichung der Arbeit verwenden:

$SPARK_HOME/bin/spark-submit --class "MyApp" --master yarn-cluster --num-executors 10 --executor-memory 14g target/scala-2.10/my-application_2.10-1.0.jar 

die Diskussion Nach mir meine Garn-site.xml Datei geändert und auch die Funken einreichen Befehl.

Hier ist der neue Garn-site.xml Code:

<property> 
<name>yarn.resourcemanager.hostname</name> 
<value>hm41</value> 
</property> 

<property> 
<name>yarn.nodemanager.resource.memory-mb</name> 
<value>14336</value> 
</property> 

<property> 
<name>yarn.scheduler.minimum-allocation-mb</name> 
<value>2560</value> 
</property> 

<property> 
<name>yarn.scheduler.maximum-allocation-mb</name> 
<value>13312</value> 
</property> 

Und der neue Befehl für die Funken einreichen ist

$SPARK_HOME/bin/spark-submit --class "MyApp" --master yarn-cluster --num-executors 4 --executor-memory 10g --executor-cores 6 target/scala-2.10/my-application_2.10-1.0.jar 

Damit ich in der Lage bin 6 Kerne auf jeder Maschine zu bekommen, aber Die Speicherauslastung jedes Knotens liegt immer noch bei 5G. Ich habe den Screenshot von SPARKUI und htop beigefügt.

Answer 1

1. withing yarn-site.xml Überprüfen, dass yarn.nodemanager.resource.memory-mb richtig eingestellt ist. In meinem Verständnis von Ihrem Cluster sollte es auf 14 GB eingestellt werden. Diese Einstellung ist dafür verantwortlich, dem YARN mitzuteilen, wie viel Speicher er auf diesem spezifischen Knoten verwenden kann.
2. Wenn Sie dies richtig eingestellt haben und 5 Server YARN NodeManager ausführen, dann ist der Auftragseingabe-Befehl falsch. Zuerst wird --num-executors die Anzahl der YARN-Container für die Ausführung auf dem Cluster gestartet werden. Sie geben 10 Container mit je 14 GB RAM an, aber Sie haben nicht so viele Ressourcen in Ihrem Cluster! Zweitens geben Sie --master yarn-cluster an, was bedeutet, dass Spark Driver innerhalb des YARN-Anwendungs-Masters ausgeführt wird, für den ein separater Container erforderlich wäre.
3. Meiner Meinung nach zeigt es 3 Container, weil von 5 Knoten im Cluster nur 4 von ihnen YARN NodeManager + Sie 14 GB für jeden der Container zuweisen, so dass YARN zuerst Application Master startet und dann die NM abfragt für verfügbare Ressourcen und sehen, dass es nur 3 Container starten kann. In Bezug auf die Größe des Heapspeichers sieht man, dass nach dem Start des Spark seine JVM-Container gefunden werden und die Parameter ihres Starts angezeigt werden - Sie sollten viele -Xmx Flags in einer einzigen Zeile haben - ein richtiger und ein falscher, Sie sollten seinen Ursprung in den Konfigurationsdateien (Hadoop) finden oder Funken)
4. Bevor eine Anwendung auf dem Cluster-Vorlage, die Funkenschale mit den gleichen Einstellungen starten (ersetzen yarn-cluster mit yarn-client) und überprüfen, wie es gestartet wird, überprüfen WebUI und JVMs gestartet

Answer 2

Speicher (7.2GB) Sie sehen in der SparkUI die spark.storage.memoryFraction, die standardmäßig 0,6 ist. Was Ihre fehlenden Executoren betrifft, sollten Sie in den YARN Resource Manager-Protokollen suchen.

Answer 3

Nur weil YARN "denkt", dass es 70GB (14GBx5) hat, bedeutet das nicht, dass zur Laufzeit 70GB auf dem Cluster verfügbar sind. Sie könnten andere Hadoop-Komponenten (Hive, HBase, Gerinne, Solr oder Ihre eigene App usw.) ausführen, die Speicher verbrauchen. Die Laufzeitentscheidung, die YARN trifft, basiert auf dem, was derzeit verfügbar ist - und es standen Ihnen nur 52 GB (3x14 GB) zur Verfügung. Übrigens, die GB-Nummern sind ungefähr, weil sie wirklich als 1024MB pro GB berechnet werden ... also sehen Sie Dezimalzahlen.

Verwenden Sie nmon oder oben, um zu sehen, was sonst Speicher auf jedem Knoten verwendet.