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. 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.

Files d'attente

Le système de gestion des travaux possède plusieurs types files d'attente:
  • partition groupe: une file d'attente par groupe primaire d'utilisateurs. Pour les jobs relativement courts (voir plus loin)
  • partition longq: tous les jobs plus longs sont aiguillés dans cette file. Contrairement aux partitions groupe, les jobs de la partition longq subissent un certain nombre de restrictions
    • nombre maximum de jobs running: 100
    • nombre maximum de jobs running par utilisateur: 10
  • partition gpu: permet d'accéder aux machines de la partition gpu (utiliser "sbatch -p gpu")
  • partition 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
  • partition imb-resources: donnant accès à des ressources financées par l'IMB, cette partition n'est accessible qu'aux utilisateurs du groupe imb (en utilisant "sbatch -p imb-resources").

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 < 17280 heures (correspond à 5 jours sur 144 cœurs ou 30 jours sur 24 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 = 128 - nombre de jobs candidats pour le backfilling