Apuntes y recomendaciones mínimos para armar scripts para SLURM
cluster. en realidad hay que ampliarlo y convertirlo en un verdadero tutorial de cómo armar script para SLURM
Algunas recomendaciones para que tengan en cuenta al armar scripts para slurm en el cluster.
Login bash
Siempre usen la opción -l para el bash que corra el script de slurm:
#!/bin/bash -l
De esa manera se ejecutan todos los scripts de inicialización de una sesión interactiva en el nodo de cálculo. Así el environment del script de slurm es el mismo que tienen Uds. al ingresar (login) al nodo.
Por ejemplo eso permite agregar al PATH todos los directorios de los distintos programas que se pueden ejecutar en el cluster.
En particular eso asegura la ejecución de todos los scripts que se encuentran en /etc/profile.d eso incluye los scripts de inicialización de varios de los paquetes de programas que se ejecutan en el cluster, además de ejecutarse los scripts que Uds. mismos puedan tener en ~/.bashrc, ~/.profile, etc.
Features & constraints
El comando
lsnodes
despliega las característias de los nodos de cálculo. En particular, la columna de más a la derecha contiene los AVAIL_FEATURES de cada nodo.
Ese listado de palabras (features) caracteriza a cada nodo: allí hay palabras que identifican el nombre, la arquitectura e incluso los nombres de los programas que pueden ejecutarse en cada uno.
Si bien cada nodo tiene su propia lista de features, hay features comunes a varios nodos.
Uds. puede usar estos features como constaraints para elegir en qué nodos desean correr su cálculo
En la opción –constraint=??? Uds. puede combinar varios features para asegurarse en qué nodos ejecutar
La “,” o el “|” actúa como el operador OR, mientras que el “&“ actúa como el operador AND
Correr en uno o más nodos
Ojo con los parámetros que especifican el número de tareas y CPUs a usar en un cálculo paralelo.
Uds. pueden creer que
--ntasks=8'' --cpus-per-task=1
y
--ntask=1 --cpus-per-task=8
es lo mismo, pero no lo es para Slurm
En el primer caso están especificando que quieren correr 8 tareas, asignando una cpu por cada tarea. En ese caso slurm puede asgirnar, uno, dos o hasta 8 nodos para ejecutar esas tareas, asignando sólo 1 tarea por nodo.
Eso puede ser lo que quieren o no: si el cálculo es “data parallel” (es decir que cada tarea corre sobre datos independientres entre sí) entonces repartir el cálculo entre 8 nodos puede ser algo deseable.
Pero si el cálculo no es data parallel, sino que existe intensa comunicación e intercambio de datos entre tareas (como pueden ser cualquiera de nuestros cálculos MPI) entonces elcorrer en múltiples nodos puede tener un impacto grande en el rendimiento y los tiempos de ejecución. Si las tareas se ejcutan en el mismo nodo, el intercambio de hace a la velocidad de la RAM, pero si las tareas se ejecutan en nodos distintos, la velocidad de intercanbio baja al de la red del cluster (de paso congestionando los switches y afectando a todos los usuarios). O sea… uno o más órdenes de magnitud más lento.
Hoy tenemos una red de 1Gbps, Si tuviésemos Infiniband o una red de 10o 100Gbps, entonces podría ser otro cantar. En el segundo caso (–ntasks=1), le estamos pidiendo que corra una única tarea, asignando 8 cpus (–cpus-per-task=8)… eso asegura que el cálculo ejecuta en un único nodo.
Hay otras opciones de sbatch y srun que también afectan este comportamiento:
--use-min-nodes --ntasks-per-socket --ntasks-per-core etc.
En resumen: RDFM