Calculer

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.

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 :

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 à 16 cœurs et 64Go de mémoire
• nœud à 24 cœurs et 128Go 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.