Jobs batch
Un job batch exécute un traitement sur les ressources d'eXplor-v2 sans intervention continue de l'utilisateur. Vous décrivez les ressources nécessaires et les commandes à exécuter dans un script, puis vous soumettez ce script avec sbatch.
Les jobs batch sont recommandés pour :
- les calculs longs ;
- les traitements reproductibles ;
- les campagnes de simulations ;
- les analyses qui doivent s'exécuter sans session ouverte ;
- les workflows comportant plusieurs étapes ;
- les traitements à relancer ou à archiver.
Un job batch demande des ressources à SLURM. Le job peut rester en attente jusqu'à ce que les ressources soient disponibles et que les règles de priorité permettent son démarrage.
Préparer un script
Un script SLURM contient généralement :
- un interpréteur, comme
#!/bin/bash; - des directives
#SBATCH; - la préparation de l'environnement ;
- les commandes du traitement.
Exemple minimal :
#!/bin/bash
#SBATCH --job-name=mon-calcul
#SBATCH --partition=std
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=8G
#SBATCH --time=01:00:00
#SBATCH --output=logs/%x-%j.out
#SBATCH --error=logs/%x-%j.err
set -euo pipefail
mkdir -p logs
module load <module>
python script.py
Remplacez <module> par le nom exact d'un module disponible et adaptez les ressources à votre application.
Directives principales
| Directive | Rôle |
|---|---|
--job-name | Nom lisible du job |
--partition | Partition à utiliser |
--account | Projet ou compte à débiter, si nécessaire |
--ntasks | Nombre de tâches ou processus |
--cpus-per-task | Nombre de CPU par tâche |
--mem | Mémoire totale demandée |
--mem-per-cpu | Mémoire demandée par CPU |
--gres=gpu:1 | Nombre de GPU demandé, selon la configuration |
--time | Durée maximale |
--output | Fichier de sortie standard |
--error | Fichier d'erreur standard |
--mail-type | Événements de notification |
--mail-user | Adresse de notification |
N'utilisez pas simultanément --mem et --mem-per-cpu sans connaître le comportement attendu de la configuration locale.
Soumettre un job
Enregistrez le script, par exemple sous :
mon-calcul.slurm
Créez le répertoire des logs si le script ne le fait pas :
mkdir -p logs
Soumettez le job :
sbatch mon-calcul.slurm
SLURM renvoie généralement un identifiant :
Submitted batch job 123456
Conservez cet identifiant pour suivre le job et consulter son historique.
Afficher ses jobs :
squeue -u "$USER"
Exemple de calcul CPU
#!/bin/bash
#SBATCH --job-name=analyse-cpu
#SBATCH --partition=std
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=32G
#SBATCH --time=04:00:00
#SBATCH --output=logs/%x-%j.out
#SBATCH --error=logs/%x-%j.err
set -euo pipefail
mkdir -p logs
module load <module>
export OMP_NUM_THREADS="$SLURM_CPUS_PER_TASK"
./mon-programme --input donnees/ --output resultats/
Le paramètre OMP_NUM_THREADS convient aux programmes OpenMP, mais uniquement si l'application utilise effectivement ce modèle de parallélisme.
Exemple de calcul GPU
#!/bin/bash
#SBATCH --job-name=calcul-gpu
#SBATCH --partition=gpu
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=32G
#SBATCH --gres=gpu:1
#SBATCH --time=02:00:00
#SBATCH --output=logs/%x-%j.out
#SBATCH --error=logs/%x-%j.err
set -euo pipefail
mkdir -p logs
module load <module-gpu>
nvidia-smi
python entrainement.py
La syntaxe exacte pour demander un modèle de GPU peut dépendre de la configuration SLURM. N'inventez pas le nom d'une contrainte : vérifiez les options autorisées avec le centre ou les informations de partition.
Exemple de job haute mémoire
#!/bin/bash
#SBATCH --job-name=analyse-memoire
#SBATCH --partition=highmem
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=16
#SBATCH --mem=512G
#SBATCH --time=08:00:00
#SBATCH --output=logs/%x-%j.out
#SBATCH --error=logs/%x-%j.err
set -euo pipefail
mkdir -p logs
./mon-programme-large
La partition highmem doit être utilisée lorsque la quantité de mémoire demandée le justifie.
Préparer l'environnement logiciel
Chargez les modules nécessaires dans le script afin de rendre le job reproductible :
module purge
module load <module-compiler>
module load <module-application>
module list
Pour Python, activez l'environnement approprié selon la procédure du centre :
which python
python --version
Évitez de dépendre uniquement de l'état de votre terminal interactif. Le script doit reconstruire l'environnement nécessaire au traitement.
Fichiers d'entrée et de sortie
Organisez séparément :
- les scripts ;
- les données d'entrée ;
- les résultats ;
- les fichiers de logs ;
- les environnements et listes de dépendances.
Exemple :
mon-projet/
├── input/
├── output/
├── logs/
├── scripts/
└── environment.yml
Utilisez %x pour le nom du job et %j pour son identifiant dans les noms de fichiers :
#SBATCH --output=logs/%x-%j.out
#SBATCH --error=logs/%x-%j.err
$HOMEUtilisez l'espace projet ou $SCRATCH selon la nature des données. Consultez Espaces de stockage.
Dépendances entre jobs
Une dépendance permet de démarrer un job uniquement lorsqu'un autre job atteint un état donné.
Soumettez un premier job :
job_preparation=$(sbatch --parsable preparation.slurm)
Soumettez un second job après la réussite du premier :
sbatch --dependency=afterok:"$job_preparation" analyse.slurm
Autres formes courantes :
--dependency=afterany:<job_id>
--dependency=after:<job_id>
--dependency=aftercorr:<job_id>
Vérifiez les formes autorisées dans la configuration locale de SLURM.
Afficher les détails d'un job :
scontrol show job <job_id>
Job arrays
Les job arrays permettent de lancer un même script avec plusieurs indices. Ils conviennent aux campagnes de traitements indépendants.
Dans le script :
#SBATCH --array=0-9
Utilisez l'indice dans le programme :
input_file="input/sample-${SLURM_ARRAY_TASK_ID}.dat"
output_file="output/result-${SLURM_ARRAY_TASK_ID}.dat"
./mon-programme "$input_file" "$output_file"
Utilisez un nom de sortie qui distingue les tâches :
#SBATCH --output=logs/%x-%A_%a.out
#SBATCH --error=logs/%x-%A_%a.err
%Acorrespond à l'identifiant principal du tableau ;%acorrespond à l'indice de la tâche.
Vous pouvez limiter le nombre de tâches simultanées :
#SBATCH --array=0-99%10
Cet exemple limite à dix tâches simultanées, selon les règles de la plateforme.
Préparer et tester avant la production
Avant de soumettre une grande campagne :
- testez le programme sur un petit jeu de données ;
- utilisez une session interactive courte ou la partition de test ;
- vérifiez les fichiers de sortie ;
- mesurez le temps et la mémoire ;
- soumettez un seul job batch ;
- lancez la campagne complète après validation.
Pour un test interactif :
salloc \
--partition=std \
--ntasks=1 \
--cpus-per-task=2 \
--mem=4G \
--time=00:15:00 \
srun --pty bash
La partition std doit être vérifiée avec sinfo, car sa disponibilité et ses limites peuvent varier.
Vérifier l'utilisation réelle
Après la fin du job, consultez les ressources utilisées :
sacct -j <job_id> \
--format=JobID,JobName,State,Elapsed,AllocCPUS,MaxRSS,AllocTRES
Ces informations permettent de vérifier :
- l'état final ;
- la durée réelle ;
- le nombre de CPU attribués ;
- la mémoire maximale utilisée ;
- les ressources CPU ou GPU demandées.
Ajustez les demandes lors des exécutions suivantes.
Erreurs fréquentes
sbatch: error: Batch job submission failed
Vérifiez :
- le nom de la partition ;
- le projet ou compte ;
- la durée demandée ;
- les ressources disponibles dans la partition ;
- la syntaxe des directives
#SBATCH.
Job en attente
Un job peut rester en attente parce que :
- les ressources sont occupées ;
- la priorité ne permet pas encore son démarrage ;
- le quota du projet est atteint ;
- les ressources demandées sont difficiles à trouver ;
- une dépendance n'est pas satisfaite.
Consultez :
squeue -j <job_id> -o "%.18i %.9P %.20j %.8T %.10M %.10l %.6D %R"
Job interrompu pour dépassement mémoire
Un dépassement mémoire peut apparaître sous l'état OOM. Augmentez progressivement --mem ou réduisez la taille du traitement par étape.
Job interrompu pour dépassement de temps
Un état TIMEOUT indique que la durée maximale a été atteinte. Mesurez le temps réel et demandez une durée adaptée, sans dépasser les limites de la partition.
Bonnes pratiques
- Utilisez un script versionné plutôt que des commandes saisies manuellement.
- Donnez un nom explicite aux jobs.
- Commencez par une petite demande de ressources.
- Testez chaque script avant une campagne.
- Utilisez les dépendances pour enchaîner les étapes.
- Utilisez les arrays pour les traitements indépendants.
- Conservez les logs et les paramètres de lancement.
- Vérifiez la consommation avec
sacct. - Ne demandez pas de GPU si le programme ne l'utilise pas.
- Utilisez
$SCRATCHpour les fichiers temporaires et l'espace projet pour les résultats à conserver. - Évitez de lancer des traitements lourds sur les nœuds de connexion.
- N'intégrez jamais de mots de passe ou de jetons dans un script.