SLURM en Pirayú
- El cluster Pirayú utiliza SLURM para administrar sus recursos. El usuario solicita un número de cores para una aplicación, y el sistema los asigna apenas tenga disponibilidad de recursos
- Para enviar trabajos se usa el comando
sbatch
desde una consola:
sbatch [opciones] script
Las opciones pueden especificarse en la consola, en un archivo de configuración o en variables de entorno; y tienen ese orden de precedencia: las primeras sobreescriben a las otras.
- Dentro del script, las opciones comienzan con #SBATCH, se ignoran los otros comentarios (líneas que comienzan con "#") y deben estar antes de cualquier comando. Por ejemplo "trabajo.sh" contiene:
#!/bin/bash
#SBATCH --job-name=prueba4 # nombre para identificar el trabajo. Por defecto es el nombre del script
#SBATCH --ntasks=10 # cantidad de cores pedidos
#SBATCH --ntasks-per-node=10 # cantidad de cores por nodo, para que agrupe o distribuya procesos
# la linea siguiente es ignorada por Slurm porque empieza con ##
##SBATCH --mem-per-cpu=4G # cantidad de memoria por core
#SBATCH --output=trabajo-%j-salida.txt # la salida y error estandar van a este archivo. Si no es especifca es slurm-%j.out (donde %j es el Job ID)
#SBATCH --error=trabajo-%j-error.txt # si se especifica, la salida de error va por separado a este archivo
#SBATCH --time=3-0 # tiempo máximo de ejecución, el formato es: dias-horas / dias-horas:minutos / horas:minutos:segundos
# aqui comienzan los comandos
mpirun /home/alquien/programa/programa_mpi
El script pide 10 cores de un mismo nodo. Para un mejor rendimiento, se recomienda para la mayoría de las aplicaciones establecer --ntasks-per-node=N
, con N igual a la cantidad de tareas si es menor a 20 ó 24 (el trabajo entra en un nodo), o usar N=20 (ó N=24, según el tipo de nodo elegido) cuando la cantidad de tareas excede ese valor.
El tiempo máximo permitido para un trabajo son 15 días, si no se especifica se asignan por defecto 4 días. Cumplido el plazo, el trabajo será cancelado con un error de TIMEOUT
. Para trabajos cortos (pocas horas/días) se recomienda indicar el tiempo porque puede permitir al planificador de Slurm insertarlo en un hueco de recursos.
Para enviarlo a la cola (no es necesario que el script tenga permiso de ejecución):
sbatch trabajo.sh
y devuelve un texto similar a
Submitted batch job 101
Luego con squeue -l
se puede ver el estado:
JOBID | PARTITION | NAME | USER | STATE | TIME | TIME_LIMI | NODES | NODELIST(REASON) |
101 | principal | prueba4 | alguien | PENDING | 0:00 | UNLIMITED | 1 | (Resources) |
100 | principalk | mpi-slur | alguien | RUNNING | 0:44 | UNLIMITED | 5 | compute-0-[2-7] |
El trabajo prueba4
ha quedado en espera (PENDING
) hasta que haya nodos suficientes/adecuados (Resources
) para que se ejecute.
El mismo script "trabajo.sh" se puede enviar con otras opciones (tienen precedencia sobre las variables SBATCH
):
sbatch --ntasks=40 --job-name=parte2 trabajo.sh
De este modo no es necesario crear o modificar un script por cada trabajo.
- Opciones útiles:
--job-name=prueba4 # nombre para identificar el trabajo. Por defecto es el nombre del script
--ntasks=N # solicita N cores, por defecto se asignan consecutivamente dentro de un nodo. Si N excede la cantidad de cores continúa en otro nodo
--cpus-per-task=C # por cada tarea solicita C cores, utilizando en total C*N cores. Es útil para código híbrido MPI+OpenMP: lanza N procesos MPI reservando C cores para cada una.
--ntasks-per-node=TPN # asigna a lo sumo TPN tareas por nodo hasta completar las ntasks, sin ocupar el resto de cores del nodo. Por ejemplo, si N=20 y TPN=10 se ocuparán 10 cores en 2 nodos
--nodes=P # solicita P nodos completos. Tener en cuenta lanzar la cantidad adecuada de procesos para que el nodo no quede subtulizado.
--mem-per-cpu=M # asigna M megabytes de memoria por cada ntask. Si no se especifica, por defecto es 6440 MB (aprox 6.3 GB). Tener en cuenta que la tarea será cancelada si excede la cantidad solicitada.
--output=trabajo-%j.salida.txt # redirige la salida del script al archivo especificado.
--error=trabajo-%j.error.txt # redirige la salida de error del script al archivo especificado.
--mail-user=alguien@mail.com.ar --mail-type=end # envía un correo cuando el trabajo finaliza correctamente o por algún error
--no-requeue # no permite que el trabajo vuelva a ejecutarse luego de un problema en los nodos u otra interrupción. Es útil si el código/aplicación utilizado no tiene capacidad de continuar desde el último estado guardado.
- Se pueden encadenar trabajos independientes para que se ejecuten siguiendo un orden:
sbatch --dependency=afterany:110 segunda_parte.sh
Las opciones posibles para --dependency
son:
afterany:job_id[:job_id...]
Este trabajo comienza cuando la ejecución del trabajo con id job_id
haya finalizado.
afterok:job_id[:job_id...]
Este trabajo comienza su ejecución luego de que el trabajo especificado en job_id
haya finalizado correctamente.
afternotok:job_id[:job_id...]
Este trabajo comienza su ejecución luego de que el trabajo especificado en job_id
haya finalizado con algún estado de error (código de sálida distinto de cero, fallo de nodo, timeout, etc.)
Como se menciona en la descripción de los equipos, este cluster posee dos tipos de CPU en los nodos: de 20 cores (2 x Xeon E5-2650 v3 @ 2.30GHz de 10 cores cada uno) y de 24 cores (2 x Xeon E5-2650 v4 @ 2.20GHz de 12 cores cada uno). Si bien los rendimientos son similares, para ciertas aplicaciones puede convenir uno u otro (por ejemplo para aplicaciones que no pueden usar más de un nodo) o garantizar que sean todos iguales. Principalmente se debe tener cuenta si se hacen pruebas de rendimiento.
Para seleccionar uno u otro se utiliza --constraint=v3-20cores
o --constraint=v4-24cores
- Recursos especiales:
El cluster tiene 5 nodos con una placa GPU Nvidia Tesla K40 cada uno (accesible a través de CUDA), y un nodo con una placa Intel Xeon Phi. Estas placas obtienen mayores rendimientos que las CPU de los nodos para algunos algoritmos/programas, y se pueden usar de forma individual o en conjunto con las CPU de los nodos. Slurm los denomina GRES y permite solicitarlos para obtener uso exclusivo de los mismos durante un trabajo.
La cantida de cada GRES es por nodo, no en total para el trabjo. Para ello es necesario especficar los recursos a usar, incluyendo los cores.
--gres=gpu --ntasks=N # usar nodos dentro de la partición "gpu" y la placa GPU por cada nodo pedido. Asigna además N cores por nodo pedido, máximo 2 cores.
--gres=mic # usar nodo dentro de la partición "gpu" y la placa Xeon Phi. Asigna además un core en el nodo. Al disponer sólo de una placa no se puede solicitar más de un nodo.
- Importante:
- Los comandos (sbatch, squeue) y opciones (--ntasks, --job-name) son sensibles a mayúsculas.
- Comandos útiles:
squeue -l # lista los trabajos en ejecución y espera
sinfo # muestra estado de los nodos de cada partición
scancel JOB_ID # cancela un trabajo
slurm j JOB_ID # muestra detalles de un trabajo