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: Feature list: x86_64,el9
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 de1
.--mem <nombre>
spécifie la quantité de mémoire demandée.
job.sh
votre script de tâche executable.
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
), l’architecture matériel et le système d’exploitation (exprimés dans Feature list sous le format architecture,système
), 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
Attention
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=<email address> # 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=<email address> # 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=<email address> # 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.
Attention
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.
% srun -t 0-08:00 -n 4 --mem 2G --pty bash -i
% srun -t 0-08:00 -n 4 --mem 2G job.sh
% 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
).
Attention
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
Note
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.
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
.
Attention
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.
Important
La version courante des pilotes Nvidia est 530.30.02-1
; la version de CUDA associée est 12.1.1-1
, la version de CUDnn est 8.9.1.23
, et celle de NCCL est 2.18.1
.
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.