🦺 Ejecución de trabajos

🦺 Ejecución de trabajos#

Para ejecutar programas se usa SLURM, que es un sistema de gestión de trabajos utilizado en clusters para distribuir y gestionar tareas de manera eficiente.

Para correr un trabajo, se necesita crear un script de lanzamiento que describa los recursos requeridos por el trabajo y las tareas que realiza. Más abajo encontrará ejemplos de scripts.

Ver también

Para usar software ya instalados en el cluster, ver el tutorial sobre modules.

Comandos básicos#

  • sbatch: Para encolar un trabajo cuyo submit script es job.sh, luego de encolar el trabajo le devolverá un número que lo identifica.

    $ sbatch job.sh
Submitted batch job 1234

  • squeue: Muestra la cola de trabajos pendientes o en ejecución.

    $ squeue --me

  • sinfo: Proporciona información sobre el estado de los nodos en el cluster.

    $ sinfo

  • scancel: Para eliminar un trabajo de la cola o cancelar su ejecución, usando el identificador del trabajo.

    $ scancel 1234

Ver trabajos encolados#

Para ver todos los trabajos pendientes y en ejecución, utilice squeue:

$ squeue
JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
55060     multi   script    alice PD       0:00      4 (Resources)
55079     multi   script    alice PD       0:00      1 (Priority)
55081     multi   script      bob PD       0:00      1 (AssocMaxJobsLimit)
55008     short   script      bob PD       0:00      1 (Dependency)
54915     multi   script    alice  R    1:27:18      4 rome[09,14,16,33]
55007     short   script      bob  R      30:58      1 rome05

Explicación:

  • JOBID: El identificador.

  • PARTITION: La cola en la que está.

  • NAME: El nombre.

  • USER: El usuario que lo encoló.

  • ST: El estado, algunos estados comunes son:

  • TIME: El tiempo que lleva ejecutando.

  • NODES: La cantidad de nodos que se solicitaron.

  • NODELIST(REASON): Los nodos en los que está corriendo el trabajo, o la razón por la que todavía no se está ejecutando. Algunas razones comunes son:

    • (Resources): No hay recursos libres en el cluster para ejecutarlo.

    • (Priority): Hay trabajos con mayor prioridad esperando a ser ejecutados.

    • (AssocMaxJobsLimit): El usuario excede la cantidad de trabajos máxima en ejecución simultánea.

    • (Dependency): El trabajo tiene dependencia sobre otro trabajo que aún no finalizó.

    • (JobHeldUser): El usuario ha suspendido el trabajo.

    • (JobHeldAdmin): Un administrador ha suspendido el trabajo.

    • (launch failed requeued held): SLURM encontró un error al iniciar el trabajo y lo ha suspendido.

    • (Nodes required for job are DOWN, DRAINED or reserved): Si alguno de los nodos que están down se levanta este job lo ocuparía.

    • Para ver la lista completa, ver la documentación de SLURM.

Ejemplos#

Hola Mundos#

A continuación unos ejemplos básicos para probar y usar de base, pero asegúrese de terminar de configurar el resto de parametros:

El script más simple posible: Corre en un sólo nodo, lanza una sola task, que usa un sólo core e imprime el nombre del nodo. Funciona en cualquiera de los clusters.

job.sh#
1#!/bin/bash
2#SBATCH --nodes=1
3#SBATCH --ntasks-per-node=1
4
5srun bash -c 'echo "Hola, me ejecuté en el nodo $SLURMD_NODENAME"'

Tarea

Pruebe cambiar #SBATCH --nodes=1 por #SBATCH --nodes=2.

Acá vamos a pedir y aprovechar un 1 nodo completo de Serafín.

El siguiente script representa nuestro programa:

hello.sh#
1#!/bin/bash
2
3echo $(date): En el nodo $SLURMD_NODENAME soy la task $SLURM_PROCID
4sleep 5 # "calculos"
5echo $(date): task $SLURM_PROCID terminó

Este es el script de lanzamiento para sbatch:

job.sh#
1#!/bin/bash
2#SBATCH --nodes=1
3#SBATCH --ntasks-per-node=64
4#SBATCH --partition=short
5
6srun hello.sh

Correrlo de la siguiente manera:

$ chmod +x hello.sh # solo una vez
$ sbatch job.sh

Tarea

Debe revisar los logs y ponga atención a los tiempos entre los dos echos.

Pruebe cambiar #SBATCH --nodes=1 por #SBATCH --nodes=2.

Pedir una GPU en Mendieta.

job.sh#
1#!/bin/bash
2#SBATCH --nodes=1
3#SBATCH --ntasks=1
4#SBATCH --partition=short
5#SBATCH --gpus-per-task=1
6
7echo En el nodo $(hostname) tengo acceso a las siguientes GPUs:
8nvidia-smi -L

Preámbulo para 2 nodos completos:

job.sh#
1#!/bin/bash
2#SBATCH --nodes=2
3#SBATCH --ntasks-per-node=64
4#SBATCH --cpus-per-task=4

Preámbulo para 1 nodo completo:

job.sh#
1#!/bin/bash
2#SBATCH --nodes=1
3#SBATCH --ntasks-per-node=32
4#SBATCH --cpus-per-task=1

Quantum Espresso#

job.sh#
 1#!/bin/bash
 2#SBATCH --job-name=espresso
 3#SBATCH --partition=multi
 4#SBATCH --nodes=1
 5#SBATCH --ntasks-per-node=64
 6#SBATCH --cpus-per-task=1
 7
 8# Cargar el entorno del usuario incluyendo la funcionalidad de modules
 9# No tocar
10. /etc/profile
11
12# Configurar OpenMP y otras bibliotecas que usan threads
13# usando los valores especificados arriba
14export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
15export MKL_NUM_THREADS=$SLURM_CPUS_PER_TASK
16
17# Cargar los módulos para la tarea
18module load quantum-espresso/7.2
19
20# Lanzar el programa
21srun pw.x -nk 1 -inp input > output
job.sh#
 1#!/bin/bash
 2#SBATCH --job-name=espresso
 3#SBATCH --partition=multi
 4#SBATCH --nodes=1
 5#SBATCH --ntasks-per-node=64
 6#SBATCH --cpus-per-task=1
 7
 8. /etc/profile
 9
10# Configurar OpenMP y otras bibliotecas que usan threads
11# usando los valores especificados arriba
12export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
13export MKL_NUM_THREADS=$SLURM_CPUS_PER_TASK
14
15# Cargar los módulos para la tarea
16module load quantum-espresso/7.1
17
18# Lanzar el programa
19srun pw.x -nk 1 -inp input > output

GROMACS#

job.sh#
 1#!/bin/bash
 2#SBATCH --job-name=gmx
 3#SBATCH --nodes=1
 4#SBATCH --ntasks=1
 5#SBATCH --cpus-per-task=64
 6#SBATCH --partition=multi
 7
 8. /etc/profile
 9module load gromacs
10srun gmx_mpi mdrun -ntomp ${SLURM_CPUS_PER_TASK} (...)
job.sh#
 1#!/bin/bash
 2#SBATCH --job-name=gmx
 3#SBATCH --nodes=1
 4#SBATCH --ntasks=1
 5#SBATCH --cpus-per-task=10
 6#SBATCH --gpus-per-task=1
 7#SBATCH --partition=multi
 8
 9. /etc/profile
10module load gromacs
11srun gmx_mpi mdrun -nb gpu -pme gpu -bonded gpu -update gpu -ntomp ${SLURM_CPUS_PER_TASK} (...)
job.sh#
 1#!/bin/bash
 2#SBATCH --job-name=gmx
 3#SBATCH --nodes=1
 4#SBATCH --ntasks=1
 5#SBATCH --cpus-per-task=64
 6#SBATCH --partition=multi
 7
 8. /etc/profile
 9module load gromacs
10srun gmx_mpi mdrun -ntomp ${SLURM_CPUS_PER_TASK} (...)

Sesión interactiva#

Se puede reservar un nodo y ejecutar comandos interactivamente

$ srun --pty bash
Sólo en Mendieta!#
$ srun --gpus=1 --pty bash

Notebook Jupyter con GPU en Mendieta#

conda activate <env>
salloc -p multi -N 1 --gres=gpu:1
srun hostname  # <= NRO_NODO
srun jupyter notebook --no-browser --port 9999 --ip 0.0.0.0

y luego

ssh -L 9999:10.10.10.$NRO_NODO:9999 $USER@mendieta.ccad.unc.edu.ar

Una guía exaustiva sobre este tema fue elaborada por la usuaria Karen Palacio y puede ser consultada aqui.

Preguntas Frecuentes#

¿Por qué SLURM no toma en cuenta el tiempo de ejecución solicitado?

En las nuevas versiones de SLURM todas las directivas del preámbulo se deben especificar en un solo bloque, es decir que apenas detecta un comando SLURM considera que llegó al final del preámbulo. Por ejemplo, el siguiente script considerará el tiempo de ejecución solicitado por el usuario, en este caso 7 días:

#!/bin/bash
#SBATCH --job-name=test
#SBATCH --partition=mono
#SBATCH --ntasks=4
#SBATCH --cpus-per-task=2
#SBATCH --time 7-0:00:00

Mientras que el siguiente script tomará como tiempo de ejecución aquel indicado en la configuración por defecto de la cola, porque la instrucción --time no va a ser tomada en consideración:

#!/bin/bash
#SBATCH --job-name=test
#SBATCH --partition=mono
#SBATCH --ntasks=4
#SBATCH --cpus-per-task=2

export MYVAR="Hello"
#SBATCH --time 7-0:00:00

¿Cómo sé si SLURM tomó en consideración todas las instrucciones especificadas en el preámbulo?

Es posible utilizar el comando scontrol para verificar que el gestor de recursos haya encolado el trabajo de acuerdo a lo solicitado en el preámbulo:

scontrol show job $JOBID

Donde la variable $JOBID debe ser reemplazada por el numero del job.