Force YARN zum Bereitstellen von Spark-Tasks für alle Slaves

Question

Ich habe das SparkPi-Beispiel auf einem Cluster mit 8 Knoten bereitgestellt. Es scheint, dass die mit dem Beispiel verbundenen Aufgaben nicht auf allen Knoten im Cluster bereitgestellt werden, obwohl der Cluster nicht ausgelastet ist (keine anderen Jobs werden ausgeführt).

Hier ist, wie ich das SparkPi Beispiel bin ab:

spark-submit --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode cluster --driver-memory 1g --executor-memory 1g --executor-cores 1 --num-executors 7 $SPARK_HOME/lib/spark-examples-1.6.1-hadoop2.6.0.jar 100000 

Allerdings, wenn ich bei dem Blick Knoten genutzt wird, ist es das, was ich sehe:

ich das Gefühl habe, das ist weil ich die CapacityScheduler im Ressourcenmanager verwende. Hier ist meine yarn-site.xml Datei:

<configuration> 
    <property> 
     <name>yarn.nodemanager.aux-services</name> 
     <value>mapreduce_shuffle</value> 
    </property> 
    <property> 
     <name>yarn.resourcemanager.hostname</name> 
     <value>master.cluster</value> 
    </property> 
    <property> 
     <name>yarn.resourcemanager.address</name> 
     <value>master.cluster:8032</value> 
    </property> 
    <property> 
     <name>yarn.resourcemanager.scheduler.address</name> 
     <value>master.cluster:8030</value> 
    </property> 
    <property> 
     <name>yarn.resourcemanager.webapp.address</name> 
     <value>0.0.0.0:8088</value> 
    </property> 
    <property> 
     <name>yarn.resourcemanager.resource-tracker.address</name> 
     <value>master.cluster:8031</value> 
    </property> 
    <property> 
     <name>yarn.resourcemanager.admin.address</name> 
     <value>master.cluster:8033</value> 
    </property> 
    <property> 
     <name>yarn.resourcemanager.admin.address</name> 
     <value>master.cluster:8033</value> 
    </property> 

    <property> 
     <name>yarn.application.classpath</name> 
     <value>/usr/local/hadoop/etc/hadoop, /usr/local/hadoop/share/hadoop/common/*, /usr/local/hadoop/share/hadoop/common/lib/*, /usr/local/hadoop/share/hadoop/hdfs/*, /usr/local/hadoop/share/hadoop/hdfs/lib/*, /usr/local/hadoop/share/hadoop/mapreduce/*, /usr/local/hadoop/share/hadoop/mapreduce/lib/*, /usr/local/hadoop/share/hadoop/yarn/*, /usr/local/hadoop/share/hadoop/yarn/lib/*</value> 
    </property> 

    <property> 
    <description> 
     Number of seconds after an application finishes before the nodemanager's 
     DeletionService will delete the application's localized file directory 
     and log directory. 

     To diagnose Yarn application problems, set this property's value large 
     enough (for example, to 600 = 10 minutes) to permit examination of these 
     directories. After changing the property's value, you must restart the 
     nodemanager in order for it to have an effect. 

     The roots of Yarn applications' work directories is configurable with 
     the yarn.nodemanager.local-dirs property (see below), and the roots 
     of the Yarn applications' log directories is configurable with the 
     yarn.nodemanager.log-dirs property (see also below). 
    </description> 
    <name>yarn.nodemanager.delete.debug-delay-sec</name> 
    <value>600</value> 
    </property> 

</configuration> 

Wie kann ich GARN optimieren, so dass sie Aufgaben über alle Knoten entfaltet?

Answer 1

Die Antwort war recht einfach, in $HADOOP_PREFIX/etc/hadoop/capacity-scheduler.xml können Sie den Standard ändern 0.1-1:

<configuration> 

    <property> 
    <name>yarn.scheduler.capacity.maximum-am-resource-percent</name> 
    <value>1</value> 
    <description> 
     Maximum percent of resources in the cluster which can be used to run 
     application masters i.e. controls number of concurrent running 
     applications. 
    </description> 
    </property> 

</configuration> 

Obwohl der Cluster nur einer Master-Anwendung ermöglicht, zu einer Zeit (meine Vorliebe) zu laufen, wird es nutzen der gesamte Cluster.

Answer 2

1. Ein Anwendungsmanager sollte nicht viel Ressourcen verbrauchen. Zu 100% zu deklarieren ist wirklich zu viel. Ich weiß nicht, was du hier gut gemacht hast (keine Ahnung).
2. Sie sollten bevorzugen, so viele Aufgaben wie möglich auf demselben Knoten auszuführen, solange Ressourcen verfügbar sind. Dadurch wird ein Overhead beim Serialisieren und Senden von Daten über das interne Netzwerk des Clusters vermieden. Sie sollten auch so viele Aufgaben wie möglich innerhalb derselben Executor-Instanz ausführen, um die gemeinsame Nutzung von Arbeitsspeicher zu ermöglichen.
3. Wenn der Kapazitätsplaner im Standard-Setup verwendet wird, berechnet er Ressourcen nur basierend auf dem Speicherbedarf und ignoriert den CPU-Footprint. Sie deklarieren den Speicherbedarf als Teil Ihrer Spark-Konfiguration und -Parameter für den Treiber, den Anwendungs-Manager (am) und den Executor. Detailliertere Informationen finden Sie in den Handbüchern zu Funken, insbesondere the part about running Spark on Yarn und Spark Configuration. Die spezifischen Funken Konfigurationen sind:
   1. spark.yarn.am.memory (config)
   2. spark.driver.memory (config)
   3. spark.executor.memory (config)

Beachten Sie, dass die Einstellungen für die Anzahl der Kerne ebenfalls wichtig sind, aber mehr von Spark selbst als von Garn verwendet werden (es sei denn, Sie ändern die Berechnung der Ressourcennutzung).

Wenn Sie Ihren einzigen Job mit 32 CPU-Kernen auf einem einzigen Knoten ausführen können, dann herzlichen Glückwunsch zu Ihrem schönen System, aber das ist wahrscheinlich die Art, wie Sie es ausführen möchten!