apache-spark - tool - spark-submit
Grupo de chispas lleno de tiempos de espera de latidos del corazón, ejecutores que salen por su cuenta (2)
Mi cluster Apache Spark está ejecutando una aplicación que me está dando muchos tiempos de espera de ejecutor:
10:23:30,761 ERROR ~ Lost executor 5 on slave2.cluster: Executor heartbeat timed out after 177005 ms
10:23:30,806 ERROR ~ Lost executor 1 on slave4.cluster: Executor heartbeat timed out after 176991 ms
10:23:30,812 ERROR ~ Lost executor 4 on slave6.cluster: Executor heartbeat timed out after 176981 ms
10:23:30,816 ERROR ~ Lost executor 6 on slave3.cluster: Executor heartbeat timed out after 176984 ms
10:23:30,820 ERROR ~ Lost executor 0 on slave5.cluster: Executor heartbeat timed out after 177004 ms
10:23:30,835 ERROR ~ Lost executor 3 on slave7.cluster: Executor heartbeat timed out after 176982 ms
Sin embargo, en mi configuración puedo confirmar que aumenté con éxito el intervalo de latido del ejecutor:
Cuando visito los registros de los ejecutores marcados como EXITED (es decir, el controlador los eliminó cuando no pudo obtener un latido), parece que los ejecutores se suicidaron porque no recibieron ninguna tarea del controlador:
16/05/16 10:11:26 ERROR TransportChannelHandler: Connection to /10.0.0.4:35328 has been quiet for 120000 ms while there are outstanding requests. Assuming connection is dead; please adjust spark.network.timeout if this is wrong.
16/05/16 10:11:26 ERROR CoarseGrainedExecutorBackend: Cannot register with driver: spark://[email protected]:35328
¿Cómo puedo desactivar los latidos del corazón y / o evitar que los ejecutores se desactiven?
La respuesta fue bastante simple. En mi spark-defaults.conf configuro el spark.network.timeout a un valor más alto. El intervalo de latido fue algo irrelevante para el problema (aunque la sintonía es útil).
Al usar spark-submit , también pude establecer el tiempo de espera de la siguiente manera:
$SPARK_HOME/bin/spark-submit --conf spark.network.timeout 10000000 --class myclass.neuralnet.TrainNetSpark --master spark://master.cluster:7077 --driver-memory 30G --executor-memory 14G --num-executors 7 --executor-cores 8 --conf spark.driver.maxResultSize=4g --conf spark.executor.heartbeatInterval=10000000 path/to/my.jar
Los latidos y los ejecutores desaparecidos que fueron asesinados por YARN casi siempre se deben a los OOM. Debe inspeccionar los registros en los ejecutores individuales (busque el texto "correr más allá de la memoria física"). Si tiene muchos ejecutores y le resulta incómodo inspeccionar todos los registros manualmente, le recomiendo que supervise su trabajo en la interfaz de usuario de Spark mientras se ejecuta. Tan pronto como una tarea falla, informará la causa en la interfaz de usuario, por lo que es fácil de ver. Tenga en cuenta que algunas tareas informarán fallas debido a ejecutores faltantes que ya han sido eliminados, así que asegúrese de ver las causas de cada una de las tareas con fallas individuales.
Tenga en cuenta también que la mayoría de los problemas de OOM se pueden resolver rápidamente simplemente repartiendo sus datos en los lugares apropiados en su código (nuevamente, consulte la interfaz de usuario de Spark para obtener sugerencias sobre dónde podría ser necesaria una llamada para repartition ). De lo contrario, es posible que desee escalar sus máquinas para adaptarse a la necesidad de memoria.