Gestionnaire de travaux
Les calculs sur le Cluster s'effectuent par l'intermédiaire d'un gestionnaire de travaux qui s'occupe de gérer la file d'attente et de lancer les calculs lorsque les ressources demandées sont disponibles.
Le gestionnaire de travaux du Cluster est SLURM (Simple Linux Utility for Resource Management).
Attention, le walltime maximum dépend du nombre de cœurs demandés.
Le tableau ci-dessous vous présente quelques exemples, la variation est linéaire.
Nombre de cœurs | Walltime (heures) |
48 | 384 |
64 | 288 |
96 | 192 |
128 | 144 |
192 | 96 |
256 | 72 |
384 | 48 |
512 | 36 |
768 | 24 |
En dessous de 48 cœurs, la limite est de 384 heures et ne dépend pas du nombre de cœurs.
Rappel : il est interdit de calculer directement sur la frontale (zeus) !
Pour effectuer des tests de courte durée, vous pouvez utiliser les machines interactives suivantes :
Type de ressources | Machine interactive |
---|---|
CPU | interactive |
Pour les tests longs, vous devez soumettre un job via le gestionnaire de travaux.
Soumission de travaux
La soumission d'un job se fait avec la commande
sbatch job.slurm
ou job.slurm est un fichier de script dans lequel sont contenues des instructions pour SLURM ainsi que des instructions pour le lancement de votre programme. Cette commande retourne un numéro de job (JOBID).
Les instructions pour SLURM commencent par l'instruction #SBATCH suivi par une option. Les principales options sont :
- Le nombre de nœuds demandés (ici 1 nœud, valeur par défaut) :
#SBATCH --nodes=1
- Le nombre de cœurs demandés par nœud (ici 1 cœur, valeur par défaut) :
#SBATCH --ntasks-per-node=1
- Le temps demandé sous la forme HH:MM:SS (ici 24 heures, valeur par défaut) :
#SBATCH --time=24:00:00
- Le nom du job tel qu'il apparaît dans les différentes commandes de SLURM :
#SBATCH --job-name=my_job
- La taille mémoire maximum demandé par nœud (ici 1024 Mo ou 1 Go, valeur par défaut) :
#SBATCH --mem=1024M
-
[Optionnel] Pour recevoir un email à la fin du job (ou en cas d'erreur) :
#SBATCH --mail-type=ALL #SBATCH --mail-user=you@univ-lille.fr
Des exemples de scripts de soumission pour chaque application sont disponibles dans le répertoire /share/doc/submission/. Si un exemple de script semble manquant, faites le nous savoir.
Des exemples plus génériques sont également disponibles en bas de cette page.
La commande pour voir l'état des jobs est :
squeue
Cette commande ne montre que vos propres jobs !
La commande pour arrêter un job est :
scancel JOBID
avec JOBID le numéro du job.
La commande pour vérifier l'état des noeuds est :
sinfo
La commande pour obtenir l'historique des jobs à partir d'une date précise est :
sacct -S MMDD
où MM correspond au mois et DD au jour.
Par exemple, pour obtenir l'historique depuis le 15 juillet :
sacct -S 0715
Vous pouvez également définir une date de fin avec l'option -E en utilisant la même syntaxe :
sacct -S MMDD -E MMDD
Régulation des ressources demandées
SLURM contrôle en permanence les ressources consommées en nombre de cœurs et en quantité de mémoire pendant l'exécution des jobs. Il arrête automatiquement les jobs qui utilisent plus de ressources que demandées.
Dans le cas ou un job dépasse la quantité mémoire demandée, le message d'erreur suivant sera indiqué dans le fichier de sortie et d'erreur de SLURM :
slurmstepd: error: Exceeded step memory limit at some point.
Il est parfois difficile d'estimer au mieux la quantité de mémoire qui sera utilisée par les calculs. Cependant, SLURM permet de connaitre la mémoire utilisée par un job après son exécution.
Après l'exécution d'un cas test similaire à vos calculs habituels vous pouvez exécuter la commande suivante :
sacct -o jobid,jobname,reqnodes,reqcpus,reqmem,maxrss,averss,elapsed -j JOBID
en remplaçant JOBID par le numéro de votre job (donné par la commande sbatch). Vous obtiendrez alors une sortie de ce type :
ReqMem MaxRSS AveRSS Elapsed ---------- ---------- ---------- ---------- 55000Mn 16? 00:08:33 55000Mn 17413256K 16269776K 00:08:33 55000Mn 17440808K 16246408K 00:08:32
ou ReqMem est la quantité de mémoire par nœud demandé avec l'option
#SBATCH --mem=55000M
MaxRss est la quantité maximale de mémoire utilisée pendant le job sur 1 nœud et AveRSS est la quantité moyenne de mémoire utilisée sur 1 nœud.
On voit ici que ce job a utilisé au maximum environ 18 Go de mémoire par nœud.
Lors de jobs similaires on pourra donc ajuster la demande mémoire en changeant l'option dans le script de soumission :
#SBATCH --mem=20G
On demande ici environ 20Go par nœud.
La commande suivante vous permet de voir ces informations pour tous les jobs qui se sont terminés depuis une date donnée sous la forme année-mois-jour :
sacct -o jobid,jobname,reqnodes,reqcpus,reqmem,maxrss,averss,elapsed -S YYYY-MM-DD
Attention, lorsque vous obtenez le message d'erreur indiquant que la limite mémoire a été dépassée, la valeur de MaxRss ne sera pas forcément supérieure à la valeur demandée car votre application aura été arrêté avant de pouvoir dépasser la limite.
Le cluster comprend 2 types de nœuds principaux (hors gpu et phi) :
- nœud à 24 cœurs et 128Go ou 192Go de mémoire
- nœud à 32 cœurs et 192Go de mémoire
Les jobs sont automatiquement placés en fonction des ressources demandées sur les différents types de nœuds.
Exemples de scripts SLURM
Des exemples de scripts SLURM pour certains codes sont disponibles sur zeus dans le répertoire :
/share/doc/submission/
Si vous disposez d'un cas test pour un module, ou qu'aucun exemple de soumission n'existe, n'hésitez pas à nous contacter pour que nous le créions.
Dans les exemples ci-dessous, il faut noter la différence entre les demandes pour les processus (MPI) et les threads (OpenMP) :
- --ntasks-per-node : nombre de processus MPI
- --cpus-per-task : nombre de threads OpenMP
Job monoprocesseur :
#!/bin/bash #SBATCH --nodes=1 #SBATCH --ntasks-per-node=1 #SBATCH --time=24:00:00 #SBATCH --job-name=my_serial_job #SBATCH --mem=1536M ./my_program
Ce script lance un job appelé my_serial_job demandant 1 cœur sur 1 nœud avec un maximum de 1536 Mo de mémoire pour une durée de 24 heures.
Job MPI :
#!/bin/bash #SBATCH --nodes=2 #SBATCH --ntasks-per-node=16 #SBATCH --time=48:00:00 #SBATCH --job-name=my_mpi_job #SBATCH --mem=4096M mpiexec ./my_program
Ce script lance un job appelé my_mpi_job demandant 16 cœurs sur 2 nœuds (donc 32 cœurs au total) avec un maximum de 4096 Mo de mémoire par nœud (donc 8 Go au total) pour une durée de 48 heures.
Job OpenMP :
#!/bin/bash #SBATCH --nodes=1 #SBATCH --ntasks-per-node=1 #SBATCH --cpus-per-task=8 #SBATCH --time=48:00:00 #SBATCH --job-name=my_openmp_job #SBATCH --mem=4096M export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK ./my_program
Ce script lance un job appelé my_openmp_job demandant 8 cœurs sur 1 nœuds avec un maximum de 4096 Mo de mémoire par nœud pour une durée de 48 heures.
Job mixte MPI + OpenMP :
#!/bin/bash #SBATCH --nodes=2 #SBATCH --ntasks-per-node=4 #SBATCH --cpus-per-task=4 #SBATCH --time=48:00:00 #SBATCH --job-name=my_mpi_openmp_job #SBATCH --mem=4096M export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK mpiexec ./my_program
Ce script lance un job appelé my_mpi_openmp_job demandant 16 cœurs (4 processus mpi utilisant chacun 4 threads OpenMP) sur 2 nœuds (donc 32 cœurs au total) avec un maximum de 4096 Mo de mémoire par nœud (donc 8 Go au total) pour une durée de 48 heures.