Projet

Général

Profil

Wiki »

Configuration du gestionnaire de job

Principe de fonctionnement

Sur jarvis, slurm (version 24.05.4) est utilisé pour gérer les files d'attente sur l'ensemble de la machine. slurm est un système distribué qui permet de gérer des files d'attente de calculs en répartissant la charge sur les ressources disponibles sur un calculateur. L'ensemble des calculs sera ainsi géré et distribué en fonction des ressources demandées par rapport aux ressources disponibles, et d'autre part suivant la politique d'attribution des ressources.

Ces ressources sont disponibles suivant des partitions définies en fonction des ressources demandées pour une simulation.

La soumission d'une simulation se fait sur la base de commandes définies dans un script de soumission lancé ensuite par la commande sbatch. Les paramètres du script peuvent être soumis directement lors de l'appel de la commande, ou directement dans le script. Par exemple :

#!/bin/bash
#
#SBATCH --job-name=LULESH-OMP4
#SBATCH --output=LULESH-OMP4.log
#
#SBATCH -n 1
#SBATCH --cpus-per-task=96
#SBATCH -p calcul
#SBATCH --time=10:00

module add compilers/gcc
# nombre de threads OpenMP : non nécessaire normalement
# export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK

# Binding
export OMP_PLACES=cores
./omp_4.0/lulesh2.0 -i 200 -s 300 -p

puis : 

$ sbatch submit.sh

Introduction

quelques commandes associées à slurm

  • Lancer un job décrit dans le script <jobscript>:

    $ sbatch <jobscript>

  • consulter la liste des jobs soumis:

    $ squeue
#ou en ajoutant un formatage différent
$ squeue -o '%A %8u %12j   %3C  %8N %2t %12l %12M %23e %10m %5Q'

  • supprimer un job (référencé par un jobid)

    $ scancel <jobid>

  • Obtenir des informations sur un job soumis:

    $ scontrol show job <jobid>
# ou
$ sacct -j <jobid> --format=User%20,JobID%20,Jobname%60,partition,state%20,time,start,end,elapsed,MaxRss,MaxVMSize,ReqMem,nnodes,ncpus,nodelist%60,submit%40

  • Connaitre les informations sur les partitions : sinfo [options]

$ sinfo 
$ sinfo --long
$ sinfo --long --Node

Configuration Scheduler

Contexte d'exécution

cgroups

Les travaux (jobs) sont confinés sur la machine dans un environnement (cgroups) qui empêche leurs processus de consommer plus de ressources CPU que ce qui a été demandé par l'utilisateur. Par exemple, si on a réservé 2 cœurs sur un nœud, les processus lancés lors de ce job ne pourront pas consommer plus que la puissance de calcul des 2 cœurs alloués. La même approche est utilisée sur la quantité de mémoire.

Durée du job

L'utilisateur doit spécifier la durée attendue (walltime) de son job au moment où il le soumet. Lors de l'exécution, le temps du job est décompté.
Si le job continue de tourner au delà de la durée demandée, celui-ci est détruit par le gestionnaire de job. Il n'y a pas de possibilité la durée walltime une fois que le job a démarré, mais on peut effectuer une modification tant que le job est en attente.

Cette contrainte permet au scheduler de planifier l'allocation des ressources.

Durée par défaut: Si l'utilisateur ne spécifie pas de durée walltime pour son job, le système lui affecte la durée par défaut pour les différentes files : par défaut le walltime est 1h

Partitions

Le système de gestion des travaux possède plusieurs types files (queue) d'attente:

  • calcul : Pour les jobs orientés calcul
  • visu : permet d'accéder aux cartes gpu pour réaliser la visualisation déportée (exemple : tache paraview)
  • interactive : permet d'utiliser la machine pour des traitements interactifs ne demandant pas de ressources gpu (exemple : tache jupyter)
Partitions Max Walltime Priority Coeurs Max
calcul 120h 10 ou 20 192
visu 12h 20 48
interactive 12h 20 48

Limites des jobs

Afin d'être éligibles à l'exécution, les jobs doivent satisfaire certaines contraintes ;

  • 192 coeurs max cumulé par utilisateur
  • 1.5 To de mémoire max cumulé par utilisateur
  • 100 jobs par utilisateur en run maximum
  • 300 jobs par utilisateur soumis maximum

Gestion des ressources

Afin de permettre un fonctionnement normal du gestionnaire de travaux, vous êtes obligés de spécifier les ressources dont vous avez besoin pour votre calcul. Dans le cas où vous omettez de les spécifier, une valeur par défaut est prise.

Les ressources importantes:

  • walltime: le nombre d'heures pendant lequel votre calcul est autorisé a tourner. Au delà, le système l'arrêtera. Valeur par défaut: 1 heure . En fonction du temps de calcul utilisé, 2 possibilité :
    • si le walltime est < 12h, la priorité est à 20, sinon une priorité plus faible sera posée (=10)
    • L'option à utiliser est --time=HH:MM:SS.
    • dans le cas de la partition calcul, il faut utiliser l'option --qos=batch_long pour avoir un walltime > 12h (jusqu'à 120h)
  • nombre de processeurs: votre calcul aura à disposition le nombre de processeurs renseigné. Vous pouvez demander un certain nombre de nœuds (défaut: 1) ainsi qu'un certain nombre de processeurs par nœuds (défaut: 1). Ceci se décompose habituellement en 2 options (--nodes=<nnodes> --tasks-per-node=<ppn>). Dans le cas d'un job avec des processus multithreadés, on devra utiliser l'option --cpus-per-task=<nthreads>.
  • mémoire: Vous pouvez demander une certaine quantité de mémoire par coeur avec l'option --mem-per-cpu= ou pour l'ensemble du job avec l'option --mem=. (ex : je demande 48Go de mémoire pour une simulation --mem=48G)

Détermination de la priorité entre jobs

Le calcul de la priorité entre les jobs prend en compte plusieurs facteurs.

Fairshare Scheduling

Le Fairshare scheduling est un système qui enregistre la consommation des ressources par les jobs selon un ensemble d'intervalles de temps. Cette comptabilité est ensuite utilisée pour favoriser les jobs des utilisateurs qui on moins consommé.

Sur jarvis, seule la consommation personnelle de l'utilisateur rentre en ligne de compte. Tous les utilisateurs sont initialement égaux par rapport au Fairshare.

Backfilling

Quand les jobs de plus grande priorité ne peuvent être exécutés immédiatement alors que certaines ressources sont disponibles (par exemple, le job de plus grande priorité requiert 96 processeurs alors que seuls 24 sont libres), le scheduler peut placer un job de plus faible priorité si son exécution ne retarde pas les autres.