Exemples de soumission

Job standard

La soumission d’un job en ligne de commande se fait avec la syntaxe suivante :

% sbatch -t 0-00:30 -n 1 --mem 2G job.sh
sbatch: INFO: Account: ccin2p3
sbatch: INFO: Submission node: cca013
sbatch: INFO: Partition set to: htc
sbatch: INFO: Partition limited to one node per job.
sbatch: INFO: Time limit set to: 0-00:30 (30 minutes)
Submitted batch job 10280305

-t <j-hh:mm>: spécifie la limite de temps evaluée. Tous les formats acceptés sont décrits dans le paragraphe Principales options de sbatch
-n <nombre>: spécifie le nombre de tâches demandés (dans cette syntaxe equivalent au nombre de cœurs). Pour un job multi-cœur, <nombre> sera plus grand de 1.
--mem <nombre>: spécifie la quantité de mémoire demandée.
job.sh: votre script de tâche exécutable.

Les trois paramètres indiqués ci-dessus doivent être toujours declarés lors d’une soumission. Le paramètre -c (nombre de CPU par tâche) peut substituer -n (voir Limites des paramètres obligatoires).

À la soumission, des informations vous sont retournées dans la sortie standard : le groupe de calcul (Account, ici ccin2p3), le nœud de soumission (ici cca013), la partition htc (par défaut) dans laquelle le job sera exécuté, ou encore l’identifiant du job contenu dans la variable d’environnement SLURM_JOB_ID (ici 10280305).

Si l’on souhaite accèder à une ressource nécessitant la déclaration, on utilisera l’option -L :

% sbatch -t 0-00:30 -n 4 --mem 2G -L sps,matlab job.sh

Important

Contrôlez que votre demande de ressources ne dépasse pas les limites matérielles des nœuds de la plateforme de calcul.

Scripts de soumission

Il est possible de spécifier des options de soumission directement dans un script utilisant l’une des syntaxes suivantes, selon les besoins de calcul. Le script pourra simplement être soumis comme suit :

% sbatch my_batch_script.sh

#!/bin/bash

# SLURM options:

#SBATCH --job-name=serial_job_test    # Nom du job
#SBATCH --output=serial_test_%j.log   # Standard output et error log

#SBATCH --partition=htc               # Choix de partition (htc par défaut)

#SBATCH --ntasks=1                    # Exécuter une seule tâche
#SBATCH --mem=2000                    # Mémoire en MB par défaut
#SBATCH --time=1-00:00:00             # Délai max = 7 jours

#SBATCH --mail-user=<e-mail>          # Où envoyer l'e-mail
#SBATCH --mail-type=END,FAIL          # Événements déclencheurs (NONE, BEGIN, END, FAIL, ALL)

#SBATCH --licenses=sps                # Déclaration des ressources de stockage et/ou logicielles

# Commandes à soumettre :

module load python
python my_python_script.py

Dans cet exemple, on met en place un environnement Python via modules afin d’exécuter my_python_script.py, qui aura besoin de la ressource de stockage SPS. L’ensemble des options Slurm sont passées via des directives #SBATCH.

Des tâches de calcul peuvent être lancées en même temps de l’intérieur d’un script avec la commande « srun », pourvu que les ressources déclarées par les lignes #SBATCH ne soient pas dépassées. Par exemple :

#!/bin/bash

#SBATCH --job-name=mulitple_jobs       # Nom du job
#SBATCH --output=mulitple_jobs_%j.log  # Standard output et error log

#SBATCH --partition=htc                # Choix de partition (htc par défaut)

#SBATCH --ntasks=2                     # Exécuter maximum deux tâches
#SBATCH --mem=2000                     # Mémoire en MB par défaut
#SBATCH --time=1-00:00:00              # Délai max = 7 jours

#SBATCH --mail-user=<e-mail>           # Où envoyer l'e-mail
#SBATCH --mail-type=END,FAIL           # Événements déclencheurs (NONE, BEGIN, END, FAIL, ALL)

#SBATCH --licenses=sps                 # Déclaration des ressources de stockage et/ou logicielles

# Commandes à soumettre :

srun -n 1 --exclusive -L sps script_sps.sh &
srun -n 1 --exclusive script_software.sh &
srun -n 1 --cpus-per-task 2 script_software.sh
wait

L’option --exclusive permet à la tâche de ne pas partager la ressource. La syntaxe bash permet de:

& : lancer les tâches en parallèle; si une tâche ne trouve pas de ressource disponible, elle reste en attente et un message de warning est écrit sur le output,
wait : attendre que toutes les tâches soient terminées avant de sortir du script.

#!/bin/bash

#SBATCH --job-name=multicpu_job       # Nom du job
#SBATCH --output=multicpu_job_%j.log  # Standard output et error log

#SBATCH --partition=htc               # Choix de partition (htc par défaut)

#SBATCH --ntasks=2                    # Exécuter maximum deux tâches
#SBATCH --mem=2000                    # Mémoire en MB par défaut
#SBATCH --time=1-00:00:00             # Délai max = 7 jours

#SBATCH --mem-per-cpu=1000            # Allouer 1G de memoire à chaque cœur
#SBATCH --cpus-per-task=4             # Allouer 4 cœurs par tâche, soit 8 cœurs au total dans cet exemple (ntasks x cpus-per-task)

#SBATCH --mail-user=<e-mail>          # Où envoyer l'e-mail
#SBATCH --mail-type=END,FAIL          # Événements déclencheurs (NONE, BEGIN, END, FAIL, ALL)

#SBATCH --licenses=sps                # Déclaration des ressources de stockage et/ou logicielles

# Commandes à soumettre :

my_multicpu_job.sh

Il faut préciser le nombre de CPUs (cpus-per-task) et la memoire par CPU (mem-per-cpu) pour éviter que tous les sous-processus lancés par my_multicpu_job.sh ne s’exécuteront que sur un seul CPU.

Important

Contrôlez que votre demande de ressources ne dépasse pas les limites matérielles des nœuds de la plateforme de calcul.

Job interactif

La soumission d’un job interactif se fait via la commande srun. Utilisez l’option -L pour les ressources nécessitant la déclaration.

Session interactive HTC.

% srun -t 0-08:00 -n 4 --mem 2G --pty bash -i

Lancement interactif d’un exécutable HTC.

% srun -t 0-08:00 -n 4 --mem 2G job.sh

Dans le cas d’un job interactif GPU il faudra préciser la partition adéquate.

% srun -p gpu_interactive -t 0-08:00 --mem 2G --gres=gpu:v100:1 --pty bash -i

-p: sélectionne la partition ;
--gres=: permet de spécifier l’utilisation d’une ressource GPU, et de la définir ;
--pty: autorise l’interactivité avec la session ouverte.

Afin de quitter sa session interactive, faire :

% exit

Job tableau

Un job tableau permet d’exécuter plusieurs fois le même script en parallèle. Il peut être utile, par exemple, pour exécuter la même simulation en parallèle pour augmenter rapidement les statistiques.

% sbatch -t 0-00:30 -n 1 --mem 2G --array=0-3 job.sh

Les jobs tableau auront des variables d’environnement supplémentaires :

SLURM_ARRAY_JOB_ID.: sera fixée à l’ID du premier job du tableau ;
SLURM_ARRAY_TASK_ID: sera fixé à la valeur de l’index du job tableau ;
SLURM_ARRAY_TASK_COUNT: sera fixé au nombre de jobs dans le tableau (dans notre exemple : 4) ;
SLURM_ARRAY_TASK_MAX: sera fixé à la valeur la plus élevée de l’index du job tableau (dans notre exemple : 0) ;
SLURM_ARRAY_TASK_MIN: sera fixé à la valeur la plus basse de l’index du job tableau (dans notre exemple : 3).

Important

Contrôlez que votre demande de ressources ne dépasse pas les limites matérielles des nœuds de la plateforme de calcul.

Job parallèle (MPI)

Il s’agit de jobs qui exécutent des opérations en parallèle, possiblement sur des serveurs de calcul différents, en utilisant une interface de type MPI à travers une connectique InfiniBand. Il faut préciser la partition hpc :

% sbatch -p hpc -t 0-02:00 -n 8 --mem 2G -N 2 job.sh

-N <nombre>: spécifie le nombre de serveurs de calcul (nœuds) requis. Dans le cas où le nombre de serveurs de calcul (option -N) est 1, il n’est pas nécessaire de l’indiquer, ni de spécifier la partition.

Attention

Pour utiliser InfiniBand avec OpenMPI il sera aussi nécessaire d’activer la variable d’environnement suivante :

% export OMPI_MCA_btl_openib_allow_ib=1

Job GPU

Ce sont des jobs qui s’exécutent sur des serveurs de calcul équipés de GPUs. Deux types de syntaxes sont permises :

% sbatch -t 0-01:00 -n 4 --mem 2G --gpus 1 job.sh

% sbatch -t 0-01:00 -n 4 --mem 2G --gres=gpu:v100:1 job.sh

Ici, on demande l’allocation d’un seul GPU, mais il est possible d’en utiliser plusieurs, jusqu’à la limite de GPUs dans le nœud correspondant. La limite du nombre de taches -n <N> est expliquée dans Limites des paramètres obligatoires.

Un seul type de GPUs est disponible actuellement au CC-IN2P3 : Nvidia V100, identifié par le mot clé v100.

Important

Contrôlez que votre demande de ressources ne dépasse pas les limites matérielles des nœuds de la plateforme de calcul.

Utiliser CUDA

Le CC-IN2P3 fournit un environnement Nvidia complet (pilotes, bibliothèques CUDA, CUDnn et NCCL), et le met à jour régulièrement. Pour connaître la version actuelle de CUDA, utilisez la commande suivante à partir d’un serveur GPU interactif :

% nvidia-smi

Dans le cas où vous seriez contraint d’utiliser une version plus ancienne, le CC-IN2P3 met à votre disposition des conteneurs Apptainer fournissant les environnements précédents. Ces images sont disponibles dans le dépôt associé :

% ls -lsah /cvmfs/singularity.in2p3.fr/images/HPC/GPU
centos7_cuda10-0_cudnn7-4-2_nccl2-4-2.simg
centos7_cuda10-0_cudnn7-6-5_nccl2-5-6.sif
centos7_cuda10-1_cudnn7-5_nccl2-4-2.simg
centos7_cuda10-1_cudnn7-6_nccl2-7-6.sif
centos7_cuda11-3_cudnn8-2-0_nccl2-9-8.sif
centos7_cuda12-1_cudnn8-9-1_nccl2-18-1.sif

Une documentation plus spécifique pour l’utilisation de tel conteneur est disponible dans le GitLab du CC-IN2P3.

Pour la syntaxe nécessaire à la soumission d’un job GPU dans un conteneur, veuillez vous référer à notre documentation relative.

Pour compiler votre code CUDA, vous devriez vous connecter sur un serveur GPU interactif et utiliser le compilateur nvcc :

% /usr/local/cuda-12/bin/nvcc

Une fois le code compilé, nous vous conseillons de sortir du serveur interactif et de soumettre vos jobs avec sbatch.

Note

Pour le profilage des jobs GPU, CUPTI (CUDA Profiling Tools Interface) est installé sur nos machines de calcul. CUPTI étant directement lié à CUDA, la version installée est la même.

Job daemon et récursivité

Pour les jobs de longue durée à petite consommation de ressources (motoring ou orchestration d’autres jobs) privilegiez la partition htc_daemon (voir Limites des paramètres obligatoires) :

% sbatch -p htc_daemon -t 90-00:00 -n 1 --mem 1G job.sh

Plus généralement, la limite de temps de calcul peut être contournée avec un script de job récursif qui se re-soumet lui-même et reste en queue tant que le premier job ne disparait pas. La ligne de commande ci-dessous doit être écrite à l’intérieur du script lui-même, de préférence au début du script.

% sbatch --dependency=afterany:$SLURM_JOBID my_batch_script.sh

$SLURM_JOBID étant l’identifiant du job en cours depuis lequel le job est lancé.

Enchaînement de jobs

Il est possible d’utiliser la notion de dépendance de Slurm pour bâtir un enchaînement (pipeline) de jobs basé sur la réalisation de conditions spécifiques :

% sbatch --dependency=<type>:job_id[:job_id][,<type>:job_id[:job_id]] -t 0-01:00 -n 2 --mem 2G job.sh

Avec les types de dépendances suivants :

after:jobid[:jobid...]: exécution possible après qu’un ou plusieurs jobs donnés (identifiés par leurs identifiants) aient été démarrés
afterany:jobid[:jobid...]: exécution possible après qu’un ou plusieurs jobs donnés soient terminés
afternotok:jobid[:jobid...]: exécution possible après qu’un ou plusieurs jobs donnés aient échoués
afterok:jobid[:jobid...]: exécution possible après qu’un ou plusieurs jobs donnés se soient terminés avec succès (code retour de 0)
singleton: exécution possible après que tous les jobs d’un même nom appartenant au même utilisateur se soient terminés.

Un exemple de construction d’un tel enchaînement est donné sur cette page.