Projet

Général

Profil

Configuration Scheduler

Contexte d'exécution

cgroups

Les travaux (jobs) sont confinés sur les nœuds de calcul 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.

Ceci permet une allocation partagée des nœuds de calcul. Plusieurs jobs peuvent donc cohabiter sur une même machine avec une relative garantie de disponibilité des ressources

accès aux nœuds de calcul

En raison du besoin de confiner les jobs dans un cgroup, la connexion directe (par ssh) aux nœuds de calcul est interdite aux utilisateurs.

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 système (Avec un message du type : "JOB ... ON ... CANCELLED AT ... DUE TO TIME LIMIT" ) . Il n'y a pas de moyen de rallonger la durée walltime une fois que le job a démarré.

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 de 1 heure.

mémoire

Mémoire par défaut: Si l'utilisateur ne spécifie pas la mémoire pour son job, le système lui affecte 1Go par cœur réservé.

En cas de dépassement de la mémoire réservée, le job est détruit. (Avec les mots clefs : OUT_OF_MEMORY , oom-kill et out-of-memory dans les messages d'erreurs)

Pour avoir toute la mémoire d'un nœud dont on prend tous les cœurs, il faut explicitement spécifier la mémoire par nœud avec l'option --mem=XXGo. XX à adapter en fonction des nœuds utilisés. Ex: 90Go pour les nœuds standards. La commande "/usr/bin/time --verbose mon_programme arguments..." permet d'évaluer la consommation mémoire maximale de "mon_programme arguments..." en regardant, en sortie, la ligne "Maximum resident set size (kbytes)".

Files d'attente

Le système de gestion des travaux possède plusieurs types files d'attente ou partitions :
  • groupe : une file d'attente par groupe primaire d'utilisateurs. Pour les jobs relativement courts (voir plus loin)
  • longq : tous les jobs plus longs sont aiguillés dans cette file. Cette partition contient tous les noeuds compute et un noeud bigmem. Contrairement aux partitions groupe, les jobs de la partition longq subissent un certain nombre de restrictions:
    • Limites appliquées sur les nœuds compute:
      • nombre maximum de jobs running: 100
      • nombre maximum de jobs running par utilisateur: 10
    • Limites appliquées sur le noeud bigmem:
      • nombre maximum de jobs running: 1
      • nombre maximum de jobs running par utilisateur: 1
  • gpu : permet d'accéder aux machines de la partition gpu (utiliser "sbatch -p gpu")
  • visu : permet d'accéder aux nœuds de visualisation déportée (voir la documentation: Visualisation déportée)
    • walltime limité à 12:00:00
    • Un seul job simultané par utilisateur
  • imb-resources : donne accès à des ressources financées par l'IMB, cette partition est accessible aux utilisateurs du groupe imb (en utilisant "sbatch -p imb-resources"), et aussi à tous les utilisateurs via une soumission en mode preemptible (voir Jobs préemptables)
  • i2m-resources : donne accès à des ressources financées par l'I2M, cette partition est accessible aux utilisateurs du groupe i2M et trefle (en utilisant "sbatch -p i2m-resources"), et aussi à tous les utilisateurs via une soumission en mode preemptible (voir Jobs préemptables)
  • preemptible : voir Jobs préemptables

Limites des jobs

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

  • Walltime la durée maximale du job
    • Walltime < 120 heures (5 jours), le job est dirigé vers la partition groupe de l'utilisateur
    • Walltime < 720 heures (30 jours), le job est dirigé vers longq
    • Walltime < 12 heures pour la file d'attente visu
  • procs*hours: il s'agit du temps total réservé pour tous les processeurs alloués au job (nb cœurs x temps d'exécution)
    • procs*Walltime < 34560 heures (correspond à 5 jours sur 288 cœurs ou 30 jours sur 48 cœurs)

Limites sur un ensemble jobs

Le nombre de ressources allouées en même temps à un utilisateur est limité. La somme des produits nombre de cœurs par durée walltime de chaque job en cours d'exécution est limitée à un certain nombre d'heures pour un même utilisateur. Les jobs qui dépassent cette limite sont simplement mis en attente même si des ressources sont disponibles. Ceci permet d'éviter qu'un utilisateur ne réserve une grande part de la machine pour un temps trop long.

La limite configurée sur Curta est de 150000 heures.

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 Curta, seule la consommation personnelle de l'utilisateur rentre en ligne de compte. Tous les utilisateurs sont initialement égaux par rapport au Fairshare.

L'utilisateur intéressé pourra consulter la documentation officielle du plugin de priorités Slurm: https://slurm.schedmd.com/priority_multifactor.html#fairshare

Prise en compte de la taille du job

Sur Curta, le scheduler de Slurm est configuré avec les options suivantes, qui accordent une meilleure priorité aux jobs demandant beaucoup de cœurs:

PriorityFlags=SMALL_RELATIVE_TO_TIME
PriorityFavorSmall=NO

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 100 processeurs alors que seuls 50 sont libres), le scheduler peut placer un job de plus faible priorité si son exécution ne retarde pas les autres.

  • bf_max_job_test = 500 - nombre de jobs candidats pour le backfilling
  • bf_max_job_user_part = 50 - nombre de jobs par utilisateur par partition candidats pour le backfilling