hadoop - retainedjobs - spark port maxretries
YARN no apropia los recursos en función de las cuotas justas cuando se ejecuta un trabajo Spark (2)
Tengo un problema para reequilibrar los recursos de trabajos de Apache Spark en colas programadas Justas de YARN.
Para las pruebas he configurado Hadoop 2.6 (también intenté 2.7) para ejecutarlo en modo pseudo-distribuido con HDFS local en MacOS. Para el envío de trabajos, se utilizó la distribución "Pre-build Spark 1.4 para Hadoop 2.6 y posterior" (intentado 1.5 también) desde el sitio web de Spark .
Cuando se prueba con la configuración básica en trabajos de Hadoop MapReduce, el Programador justo funciona como se esperaba: cuando los recursos del clúster superan un máximo, se calculan las cuotas justas y los recursos para trabajos en colas diferentes se suponen y se equilibran según estos cálculos.
La misma prueba se ejecuta con trabajos de Spark, en ese caso, YARN está haciendo cálculos correctos de las partes de la feria para cada trabajo, pero los recursos para los contenedores de Spark no se reequilibran.
Aquí están mis archivos conf:
$ HADOOP_HOME / etc / hadoop / yarn-site.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.nodemanager.aux-services.spark_shuffle.class</name>
<value>org.apache.spark.network.yarn.YarnShuffleService</value>
</property>
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>
<property>
<name>yarn.scheduler.fair.preemption</name>
<value>true</value>
</property>
</configuration>
$ HADOOP_HOME / etc / hadoop / fair-scheduler.xml
<?xml version="1.0" encoding="UTF-8"?>
<allocations>
<defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
<queue name="prod">
<weight>40</weight>
<schedulingPolicy>fifo</schedulingPolicy>
</queue>
<queue name="dev">
<weight>60</weight>
<queue name="eng" />
<queue name="science" />
</queue>
<queuePlacementPolicy>
<rule name="specified" create="false" />
<rule name="primaryGroup" create="false" />
<rule name="default" queue="dev.eng" />
</queuePlacementPolicy>
</allocations>
$ HADOOP_HOME / etc / hadoop / core-site.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>
$ HADOOP_HOME / etc / hadoop / core-site.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
</configuration>
Y el caso de prueba es:
Ejecute un trabajo en la cola "prod" con un peso de 40 (debe asignar el 40% de todos los recursos), como se esperaba, el trabajo necesita todos los recursos gratuitos necesarios (62,5% de los recursos de clústeres).
./bin/spark-submit --class org.apache.spark.examples.SparkPi /
--master yarn-cluster /
--driver-memory 512M /
--executor-memory 768M /
--executor-cores 1 /
--num-executors 2 /
--queue prod /
lib/spark-examples*.jar 100000
Después de ejecutar el mismo trabajo en la cola "dev.eng" con un peso de 60, eso significa que el trabajo debe asignar el 60% de todos los recursos y disminuir los recursos del primer trabajo a ~ 40%.
./bin/spark-submit --class org.apache.spark.examples.SparkPi /
--master yarn-cluster /
--driver-memory 512M /
--executor-memory 768M /
--executor-cores 1 /
--num-executors 2 /
--queue dev.eng /
lib/spark-examples*.jar 100000
Lamentablemente, los recursos del clúster no están cambiando: el 62,5% para el primer trabajo y el 37,5% para el segundo.
Debe establecer uno de los tiempos de espera de prioridad en su asignación xml. Uno para compartir el mínimo y uno para compartir, ambos están en segundos. Por defecto, los tiempos de espera no están configurados.
De Hadoop: The Definitive Guide 4th Edition
Si una cola espera mientras su tiempo de espera de preferencia de acción mínima no recibe su parte garantizada mínima, entonces el planificador puede anticiparse a otros contenedores. El tiempo de espera predeterminado se establece para todas las colas a través del elemento de nivel superior defaultMinSharePreemptionTimeout en el archivo de asignación, y en una base por cola estableciendo el elemento minSharePreemptionTimeout para una cola.
Del mismo modo, si una cola permanece por debajo de la mitad de su parte justa durante el tiempo límite de preferencia de acción justa, entonces el planificador puede adelantarse a otros contenedores. El tiempo de espera predeterminado se establece para todas las colas a través del elemento de nivel superior defaultFairSharePreemptionTimeout en el archivo de asignación, y en una base por cola estableciendo fairSharePreemptionTimeout en una cola. El umbral también puede cambiarse de su valor predeterminado de 0.5 al establecer defaultFairSharePreemptionThreshold y fairSharePreemptionThreshold (por cola).
Fair Scheduler no mata contenedores para el primer trabajo, solo espera hasta que algunos recursos se liberen y los reserve para ser utilizados por el segundo trabajo. Si no se liberan recursos desde el primer trabajo, el planificador no puede asignar esos recursos al segundo trabajo.
En las tareas de MapReduce, cada tarea de mapa o reducción requiere crear una instancia de un nuevo contenedor y el planificador puede bloquear el trabajo para instanciar nuevos contenedores si ha excedido su presupuesto (en función de la capacidad de la cola).
En Spark las cosas son diferentes, los ejecutores se inician al comienzo del trabajo y las diferentes tareas (etapas) se envían a ellos. Entonces los recursos no se liberan y no se pueden reasignar.
Puede ser la asignación dinámica podría ayudar: http://spark.apache.org/docs/1.6.1/configuration.html#dynamic-allocation