Depuración de cuellos de botella de rendimiento
Si ejecuta una aplicación de informática de alto rendimiento (HPC) en un gran número de máquinas virtuales (más de 16), es mejor empezar a ejecutar un problema más pequeño en menos máquinas virtuales. Esa prueba comprueba que la aplicación de HPC se ejecuta según lo esperado.
No asuma que solo porque ejecute una aplicación paralela de HPC, su tiempo de reloj (tiempo real transcurrido) continuará reduciéndose a medida que la ejecute en más máquinas virtuales (con más procesos paralelos). De hecho, muchas aplicaciones de HPC estrechamente acopladas pueden tener un tiempo de reloj más largo al intentar ejecutarlas en otras máquinas virtuales.
Ese tiempo de reloj más largo se puede producir por varias razones. Por ejemplo:
Puede implementar un algoritmo paralelo de forma ineficiente.
El tamaño del problema, que es el tamaño del modelo o el número de grados de libertad (NDOF), no es suficientemente grande. A medida que la aplicación se ejecuta en más procesos paralelos, la cantidad de cálculo por cada proceso es demasiado pequeña. Como resultado, el tiempo de comunicación entre los procesos paralelos domina el tiempo total. El aumento en el tiempo de comunicación aumenta el tiempo de reloj total.
Es fundamental conocer la capacidad de escalabilidad de su aplicación de HPC en relación al tamaño del problema que le interesa. Después, puede determinar qué eficiencia paralela es aceptable desde el punto de vista del rendimiento y el costo.
La siguiente fórmula de aceleración paralela mide cómo mejora el rendimiento de la aplicación paralela a medida que se añaden más procesos paralelos:
$${\text{Parallel speed-up}} = {\dfrac{\text{Wall time (1 process)}}{\text{Wall time (n processes)}}}$$
La siguiente fórmula de eficiencia paralela ilustra la eficiencia con la que se usan los recursos de cálculo a medida que se agregan más procesos para mejorar el rendimiento de las aplicaciones paralelas:
$${\text{Parallel efficiency}} = {\dfrac{\text{Parallel speed-up}}{\text{N processes}}}$$
Si no está seguro del rendimiento de escalado paralelo de la aplicación de HPC estrechamente acoplada, ejecute un estudio de escalado. En otras palabras, ejecute la aplicación en 1, 2, 4, 8, 16, etc. procesos paralelos. Calcule la aceleración paralela y la eficiencia paralela y, a continuación, decida en función de estos resultados cuántos procesos paralelos desea usar.
Considere la posibilidad de deshabilitar los servicios innecesarios que puedan afectar al escalado paralelo, como el agente de Linux de Azure, antes de ejecutar los trabajos. Después, puede volver a habilitar los servicios una vez que hayan finalizado los trabajos. Esta recomendación es especialmente válida si usa todos los núcleos disponibles y escala a un gran número de máquinas virtuales.
Para detener el agente de Linux de Azure, use el comando siguiente:
sudo system stop waagent.service
Comprobaciones de rendimiento
La información siguiente proporciona algunas comprobaciones básicas para ayudar a identificar posibles problemas de rendimiento.
Comprobación de que se está ejecutando el número correcto de procesos y subprocesos en cada máquina virtual
Una manera fácil de determinar si usa el número correcto de procesos y subprocesos en cada máquina virtual (VM) consiste en obtener la media de carga del sistema en cada máquina virtual con una herramienta como uptime. El número debe ser aproximadamente igual al número total esperado de procesos y subprocesos en cada máquina virtual. Si la media de carga registrada es menor o mayor que el número total esperado de procesos y subprocesos, significará que hay un problema que se debe corregir.
Debe comprobar detenidamente los argumentos de la interfaz de paso de mensajes (MPI) y cómo especifica el número de subprocesos paralelos. Por ejemplo, compruebe los argumentos de línea de comandos de la aplicación o los valores de las variables de entorno, como OMP_NUM_THREADS.
Comprobación de que los procesos y subprocesos se distribuyen uniformemente entre todos los dominios de nodo NUMA
Si usa la herramienta top o htop, puede seleccionar la vista de dominio de nodo de acceso a memoria no uniforme (NUMA) si especifica 2 como parámetro de línea de comandos. (Por ejemplo: en HB120_v2, debería ver 30 dominios de nodo NUMA con esta vista).
El porcentaje de utilización de los usuarios se debe distribuir uniformemente entre todos los dominios NUMA. Si no es así, compruebe los argumentos de la línea de comandos de MPI y las variables de entorno.
En la imagen siguiente se muestra el resultado de la herramienta top de Linux en la vista NUMA. En este caso, cada NUMA se usa en un 50 %.
Comprobación del estado de ejecución de procesos y subprocesos
Para comprobar el estado de ejecución de los procesos y subprocesos, debe usar top. Idealmente, todos los procesos y subprocesos deberían estar en un estado de ejecución (R).
Si algunos de los procesos y subprocesos (o todos) se encuentran en un estado de suspensión ininterrumpida (D) o suspensión (S), investigue la situación para comprender el motivo. En función de cómo esté diseñado el algoritmo de la aplicación, el comportamiento normal y esperado de los procesos y subprocesos podría ser un estado de suspensión. Sin embargo, podría indicar una restricción de recursos, como tener un rendimiento de E/S insuficiente debido a la solución de almacenamiento que se usa.
La siguiente fórmula ilustra la eficiencia con la que se ejecuta la aplicación paralela, si espera algunos recursos del sistema (por ejemplo, E/S) y en qué medida:
$${\text{Application wait time}} = {\text{Wall time}} - \left( {\dfrac{\text{Total CPU time for all parallel processes}}{\text{Number of parallel processes}}} \right)$$
Comprobación de si la aplicación está limitada por la E/S
La existencia de procesos y subprocesos que pasan una cantidad significativa de tiempo en un estado de suspensión ininterrumpida (D) o suspensión (S) puede indicar que hay un cuello de botella de E/S que se debe investigar. Algunas aplicaciones de HPC proporcionan la generación de perfiles de rendimiento como parte de la salida. En estos perfiles se muestra el porcentaje de tiempo invertido en E/S y las tasas de E/S de lectura/escritura, lo que también puede indicar un cuello de botella de E/S.
Si no está seguro de hacia dónde va su E/S, puede utilizar herramientas como iostat como ayuda. Para comprobar si tiene un problema de E/S, cambie la solución de almacenamiento por algo que sabe que es más rápido de lo que ha usado. Después, vuelva a ejecutar la aplicación de HPC. Por ejemplo, puede usar un disco SSD NVMe local rápido o RAM.
Después de realizar este cambio, hágase las siguientes preguntas: ¿Hay alguna mejora en el tiempo de E/S? ¿Se ha mejorado el tiempo real total? Si es así, ¿en qué medida?
Comprobación de si la aplicación está limitada por la red
Determine qué porcentaje del tiempo de reloj total de la aplicación invierte en realizar la comunicación del proceso (que suele ser la comunicación de MPI).
Si la aplicación está limitada por la red, compruebe que usa la red InfiniBand al ejecutar la aplicación de HPC. Si hay una versión paralela híbrida disponible, debe determinar si esto reduce el tiempo de comunicación de la red.
Si tiene acceso al código fuente, compruebe si hay formas más eficaces de implementar la comunicación. Por ejemplo, use operaciones colectivas en lugar de punto a punto, o pruebe a usar la comunicación asincrónica en lugar de sincrónica.