Estoy tratando de comprender la relación del número de núcleos y el número de ejecutores cuando se ejecuta una Chispa de trabajo en HILO.

El entorno de prueba es como sigue:

  • Número de datos de los nodos: 3
  • Nodo de datos de la máquina especificaciones:
    • CPU: Core i7-4790 (# de núcleos: 4, número de hilos: 8)
    • RAM: 32 GB (8 GB x 4)
    • HDD: 8 TB (2 TB x 4)
  • De red: 1 gb

  • Spark versión: 1.0.0

  • Hadoop versión: 2.4.0 (Hortonworks HDP 2.1)

  • Chispa de flujo de trabajo: sc.archivo de texto -> filtro> mapa -> filtro> mapToPair -> reduceByKey -> mapa -> saveAsTextFile

  • Datos de entrada

    • Tipo: simple archivo de texto
    • Tamaño: 165GB
    • Número de líneas: 454,568,833
  • Salida

    • Número de líneas después de la segunda filtro: 310,640,717
    • Número de líneas del archivo de resultado: 99,848,268
    • Tamaño del archivo de resultado: 41GB

El trabajo se ejecute con las siguientes configuraciones:

  1. --master yarn-client --executor-memory 19G --executor-cores 7 --num-executors 3 (ejecutores por nodo de datos, uso tanto como núcleos)

  2. --master yarn-client --executor-memory 19G --executor-cores 4 --num-executors 3 (# de núcleos reducidos)

  3. --master yarn-client --executor-memory 4G --executor-cores 2 --num-executors 12 (menos núcleo, más albacea)

Tiempo transcurrido:

  1. 50 min 15 seg

  2. 55 min 48 seg

  3. 31 min 23 sec

Para mi sorpresa, (3) era mucho más rápido.

Pensé que (1) sería más rápido, ya que habría menos inter-ejecutor de comunicación cuando se baraja.

Aunque, número de núcleos de (1) es menos de (3), número de núcleos no es el factor clave desde el 2) no funcionan bien.

(Seguidores fueron añadidos después de pwilmot la respuesta.)

Para la información, el monitor de rendimiento de captura de pantalla es la siguiente:

  • Ganglios nodo de datos de resumen para (1) – trabajo comenzó a las 04:37.

Apache Spark: El número de núcleos vs el número de ejecutores

  • Ganglios nodo de datos de resumen para (3) – trabajo comenzó a las 19:47. Por favor, ignore el gráfico antes de ese tiempo.

Apache Spark: El número de núcleos vs el número de ejecutores

El gráfico aproximadamente se divide en 2 secciones:

  • Primero: desde el inicio hasta el reduceByKey: la CPU, no la actividad de la red
  • Segundo: después de reduceByKey: CPU baja, de la red de e/S se realiza.

Como muestra el gráfico, (1) se puede utilizar como parte de energía de la CPU como se le ha dado. Así, podría no ser el problema de que el número de los hilos.

Cómo explicar este resultado?

  • Ahora estoy sospechando de GC… De hecho, en la Chispa de interfaz de usuario el tiempo total empleado para la GC es superior en 1) a 2).
  • ¿Por qué no intenta 3) con 19G? Podría ser que la restricción de los trabajadores en 4G reducir el NUMA efecto que algunos ppl tiene lugar? yo.e su 4G se encuentra en uno de los 2 núcleos asignado a su flujo de trabajo y por lo tanto no es menos i/o desaceleración, que conduce a la mejor de las actuaciones. De lo contrario, creo que una de las principales pregunta es: cuántos núcleos/subproceso puede utilizar un único ejecutor de un trabajador? (Sólo se puede especificar el número total de núcleos para un trabajador, no en la granularidad del ejecutor)
  • Por cierto, acabo de comprobar el código en el core/src/main/scala/org/apache/spark/deploy/trabajador/ExecutorRunner.scala y parece que 1 ejecutor = 1 trabajador del hilo.
  • un poco tarde pero aquí hay un post en cloudera sobre este tema: blog.cloudera.com/blog/2015/03/…
  • Por cierto, he encontrado esta información en un cloudera deslice la cubierta de slideshare.net/cloudera/… , que explica un poco acerca de los responsables de la toma de decisiones en los ejecutores ,de los núcleos y la memoria
  • Cuántos núcleos están disponibles en el hilo del administrador de recursos. Puede usted por favor agregar que el fragmento aquí

InformationsquelleAutor zeodtr | 2014-07-08

8 Comentarios

  1. 54

    Para poder hacer todo esto un poco más concreto, he aquí un ejemplo de configuración de una Chispa de la aplicación para utilizar como parte de los clúster como
    posible: Imaginar un clúster con seis nodos ejecución NodeManagers, cada
    equipado con 16 núcleos y 64 gb de memoria. El NodeManager capacidades,
    hilo.nodemanager.de los recursos.memoria-mb y
    hilo.nodemanager.de los recursos.cpu-vcores, probablemente sea a 63 *
    1024 = 64512 (megabytes) y 15 respectivamente. Hemos de evitar la asignación de 100%
    de los recursos para los HILADOS de recipientes debido a que el nodo necesidades de algunos de los
    los recursos para ejecutar el sistema operativo y Hadoop demonios. En este caso, se deja un
    gigabyte y un núcleo de estos procesos del sistema. Cloudera Manager ayuda
    por la contabilidad para estos y configuración de estas características del HILO
    automáticamente.

    El probable primer impulso sería el uso de –num-ejecutores 6
    –ejecutor-núcleos de 15 –ejecutor de la memoria 63G
    . Sin embargo, este es el enfoque equivocado porque:

    63GB + el ejecutor de sobrecarga de la memoria que no caben dentro de la 63GB capacidad
    de la NodeManagers. La aplicación de master tendrá un núcleo en uno
    de los nodos, lo que significa que no habrá espacio para un 15 de núcleo ejecutor
    en ese nodo. 15 núcleos por albacea puede llevar a malas HDFS de e/S
    rendimiento.

    Una mejor opción sería el uso de –num-ejecutores 17
    –ejecutor-núcleos de 5 –ejecutor de la memoria 19G
    . Por qué?

    Esta config resultados en tres ejecutores en todos los nodos, excepto la
    con el AM, que tendrá dos ejecutores.
    –ejecutor de la memoria se deriva como (63/3 figura ejecutores por nodo) = 21. 21 * 0.07 = 1.47. 21 – 1.47 ~ 19.

    La explicación fue dada en un artículo en Cloudera del blog, Cómo optimizar Tu Apache Spark de Puestos de trabajo (Parte 2).

    • «Esta config resultados en tres ejecutores en todos los nodos excepto el uno con el AM, que tendrá dos ejecutores. «. ¿Qué significa esto en relación con «–ejecutor-núcleos de 5»?
    • Significa que cada ejecutor utiliza 5 núcleos. Cada nodo tiene 3 ejecutores, por tanto, el uso de 15 núcleos, a excepción de uno de los nodos también se ejecuta la aplicación principal para el trabajo, por lo que sólo puede alojar 2 ejecutores decir, 10 núcleos en uso como ejecutores.
    • Muy bien explicado – por favor, tenga en cuenta que esto se aplica a yarn.scheduler.capacity.resource-calculator movilidad, que es el valor predeterminado. Esto es porque por defecto de horarios por la Memoria y no por la CPU.
    • Más ejecutores puede llevar a malas HDFS de e/S de rendimiento. Así que si no lo estoy usando HDFS a todos, en ese caso, ¿puedo usar más de 5 núcleos por albacea?
    • Yo, sin embargo, la Aplicación de maestro se ejecuta en cada Nodo. Por arriba, lo que significa que habría sólo 1 Aplicación Maestra para ejecutar el trabajo. Es eso correcto?
    • Yo todavía no entiendo cómo OP llegó a las 5 de la albacea de los núcleos. Puede también ser de 3 ejecutor núcleos, 28 ejecutores? o cualquier otra combinación, siempre y cuando usamos el número de núcleos? O es que hay una fórmula para determinar primero el número de ejecutor de los núcleos?
    • tbh es una locura que la gente necesita para pensar acerca de estas cosas, la plataforma que se utiliza debe administrar. Nuevos Chispa versiones tienen más flexible configuración para un máximo de asignación en lugar de los detalles. Sí tienes razón podría ser alguna otra configuración, mientras que el balance de la cpu, de memoria y de e / s por ejecutor dado el host del nodo especificaciones. No hay duro y rápido de la fórmula, y es altamente dependiente de su trabajo específico. Hay una hoja de cálculo en este blog que encontré muy útil para comprender los posibles ajustes: c2fo.io/c2fo/spark/aws/emr/2016/07/06/…

  2. 14

    Cuando ejecute la chispa de la aplicación en la parte superior de HDFS, según Sandy Ryza

    Me he dado cuenta de que el HDFS cliente tiene problemas con toneladas de concurrentes
    los hilos. Un cálculo aproximado es que en la mayoría de los cinco tareas de cada ejecutor puede
    lograr la plena escribir rendimiento, por lo que es bueno para mantener el número de
    núcleos por albacea por debajo de ese número.

    Así que creo que su primera configuración es más lenta que la tercera parte es debido a la mala HDFS rendimiento de e/S

  3. 11

    Yo no he jugado con estos ajustes de mí mismo, así que esto es sólo una especulación, pero si nos ponemos a pensar esta cuestión de lo normal núcleos e hilos en un sistema distribuido, a continuación, en el clúster puede utilizar hasta 12 núcleos (4 * 3 máquinas) y 24 hilos (8 * 3 máquinas). En sus dos primeros ejemplos que usted está dando a su trabajo de un buen número de núcleos (potencial de la computación en el espacio), pero el número de hilos (puestos de trabajo) para que se ejecute en los núcleos es tan limitado que no son capaces de utilizar la mayor parte de la potencia de procesamiento asignado y por lo tanto el trabajo es más lento aunque hay más de cálculo de los recursos asignados.

    usted menciona que su preocupación estaba en el shuffle paso – si bien es bueno para limitar la sobrecarga en el shuffle paso es generalmente mucho más importantes para utilizar la paralelización del clúster. Pensar sobre el caso extremo – un solo subproceso programa con cero shuffle.

    • Muchas gracias por tu respuesta. Pero sospecho que el número de hilos no es el principal problema. He añadido el monitoreo de la captura de pantalla. Como muestra el gráfico, 1) se puede utilizar como parte de energía de la CPU como se le ha dado.
    • pwilmot es correcto – usted necesita 2-4 tareas MÍNIMO, a fin de aprovechar todo el potencial de sus núcleos. Pongámoslo de esta era que suelen utilizar al menos 1000 particiones para mi el 80 núcleo de clúster.
    • Lo que quiero saber es la razón de la diferencia de rendimiento entre el 1) y 3). Cuando veo la Chispa de la interfaz de usuario, tanto corre el 21 de tareas en paralelo en la sección 2. (¿por qué 21 en lugar de 24 en el caso de 3) se desconoce por ahora) Pero, las tareas para las 3) sólo se ejecuta más rápido.
  4. 4

    Respuesta corta: creo que tgbaggio que es correcto. Usted golpea HDFS rendimiento de los límites de sus ejecutores.

    Creo que la respuesta que aquí puede ser un poco más simple que algunas de las recomendaciones aquí.

    La clave para mí está en el clúster gráfico de la red. Para ejecutar 1 la utilización es constante en ~50 M bytes/seg. Para ejecutar 3 la constante utilización se duplicó, de alrededor de 100 M bytes/s.

    De el cloudera blog compartida por DzOrd, se puede ver esta importante cita:

    Me he dado cuenta de que el HDFS cliente tiene problemas con toneladas de subprocesos simultáneos. Un cálculo aproximado es que en la mayoría de las cinco tareas de cada ejecutor puede lograr la plena escribir rendimiento, por lo que es bueno para mantener el número de núcleos por albacea por debajo de ese número.

    Así que, vamos a hacer un par de cálculos, véase lo que el rendimiento esperamos que si que es cierto.


    Ejecutar 1: 19 GB, 7 núcleos, 3 ejecutores

    • 3 ejecutores x 7 hilos = 21 hilos
    • con 7 núcleos por albacea, esperamos limitada IO a HDFS (se maximiza a ~5 núcleos)
    • el rendimiento efectivo ~= 3 ejecutores x 5 hilos = 15 hilos

    3: 4 GB, 2 núcleos, 12 ejecutores

    • 2 ejecutores x 12 hilos = 24 hilos
    • 2 núcleos por el ejecutor, por lo que hdfs el rendimiento es aceptar
    • el rendimiento efectivo ~= 12 ejecutores x 2 hilos = 24 hilos

    Si el trabajo es 100% limitado por la concurrencia (el número de hilos). Esperaríamos que el tiempo de ejecución se perfectamente correlaciona inversamente con el número de subprocesos.

    ratio_num_threads = nthread_job1 /nthread_job3 = 15/24 = 0.625
    inv_ratio_runtime = 1/(duration_job1 /duration_job3) = 1/(50/31) = 31/50 = 0.62
    

    Así ratio_num_threads ~= inv_ratio_runtime, y parece que están de red limitada.

    Este mismo efecto se explica la diferencia entre 1 y carrera 2.


    De ejecución 2: 19 GB, 4 núcleos, 3 ejecutores

    • 3 ejecutores x 4 hilos = 12 hilos
    • con 4 núcleos por albacea, ok IO a HDFS
    • el rendimiento efectivo ~= 3 ejecutores x 4 hilos = 12 hilos

    Comparando el número de efectivos de los hilos y el tiempo de ejecución:

    ratio_num_threads = nthread_job2 /nthread_job1 = 12/15 = 0.8
    inv_ratio_runtime = 1/(duration_job2 /duration_job1) = 1/(55/50) = 50/55 = 0.91
    

    No es tan perfecta como la última comparación, pero todavía vemos una gota similar en rendimiento cuando perdemos hilos.

    Ahora para el último bit: ¿por qué es el caso de obtener un mejor rendimiento con más hilos, esp. más subprocesos que el número de Cpu?

    Una buena explicación de la diferencia entre el paralelismo (lo que se consigue al dividir los datos en varias CPUs) y la simultaneidad (lo que obtenemos al uso de múltiples hilos para hacer el trabajo en una sola CPU) se proporciona en este gran post de Rob Pike: La simultaneidad no es el paralelismo.

    La explicación más sencilla es que si una Chispa de trabajo es la interacción con un sistema de archivos de red o la CPU gasta un montón de tiempo de espera en la comunicación con los interfaces y no gastar un montón de tiempo realmente «hacer el trabajo». Dando a los CPUs más de 1 tarea en la que trabajar en un momento, se están gastando menos tiempo esperando y más tiempo de trabajo, y a ver mejor rendimiento.

  5. 3

    De la excelente recursos disponibles en RStudio del Sparklyr página del paquete:

    CHISPA DEFINICIONES:

    Puede ser útil ofrecer algunas definiciones simples
    para la Chispa de la nomenclatura:

    Nodo: Un servidor

    Trabajador Nodo: es Un servidor que es parte del clúster y están disponibles para
    ejecutar Chispa trabajos

    Nodo maestro: El servidor que las coordenadas de los nodos de trabajo.

    Ejecutor: Una especie de máquina virtual dentro de un nodo. Un Nodo puede tener
    varios Albaceas.

    Controlador de Nodo: El Nodo que inicia la Chispa de la sesión. Normalmente,
    este será el servidor donde sparklyr se encuentra.

    Conductor (Ejecutor): El Controlador de Nodo también se muestran en el Ejecutor
    lista.

  6. 0

    Creo que una de las razones principales es la localidad. Su tamaño del archivo de entrada es de 165 G, el archivo relacionado con los bloques sin duda distribuido en varios DataNodes, más ejecutores puede evitar la copia de red.

    Intenta establecer ejecutor num igualdad de bloques de contar, creo que puede ser más rápido.

  7. 0

    Hay un pequeño problema en las dos Primeras configuraciones creo. Los conceptos de hilos y núcleos como sigue. El concepto de roscar es si los núcleos son ideales, a continuación, utilizar ese núcleo de procesar los datos. Por lo que la memoria no es totalmente utilizada en los dos primeros casos. Si quieres marca de banco este ejemplo elegir las máquinas que tiene más de 10 núcleos en cada máquina. Luego de hacer la marca de banco.

    Pero no dan más de 5 núcleos por ejecutor habrá cuello de botella en el rendimiento de e/s.

    Así que las mejores máquinas para hacer esto de la marca del banco podrían ser los datos de los nodos con 10 núcleos.

    Nodo de datos de la máquina especificaciones:
    CPU: Core i7-4790 (# de núcleos: 10, número de hilos: 20)
    RAM: 32 GB (8 GB x 4)
    HDD: 8 TB (2 TB x 4)

    • Cna por favor compartir el el hilo de recursos pesebre fragmento

Dejar respuesta

Please enter your comment!
Please enter your name here