Piorité d'un job

Cet article explique le mode de calcul de la priorité d'un job. Cette priorité va déterminer l'ordre de lancement des jobs (passage du statut PENDING au statut RUNNING).

• Slurm : Accounting and Resource Limits
• Slurm : Multifactor Priority Plugin
• Fichier de configuration : slurm.conf
• Commande pour visualiser la priorité : sprio
• Commande pour visualiser le fair-share : sshare
• Commande pour voir les mesures d'utilisation : sreport

Dans notre configuration, 2 critères sont pris en compte pour le calcul de la priorité (utilisation du plugin multi-factor) :

• Le partage équitable (fair-share)
• La partition

La commande sprio affiche la liste des jobs en attente et le calcul de priorité réalisé par slurm

• La valeur de priorité est un entier dans [0; 4294967295]
• Par défaut, les valeurs de chaque facteur du calcul sont affichées après application du poids dudit facteur
• sprio -w permet de vérifier le poids affecté à chaque facteur
• Option -l : affichage format long
• Option -u USER : filtre sur un utilisateur
• Option -o "%.9i %.14u %.8Y %.8A %.8a %.8F %.8f %.8P %.8p" : affichage détaillé

Job_priority =
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightPartition) * (partition_factor) +

Job_priority : entier [0; 4294967295]

*_factor : réel [0; 1.0]

Les poids de chaque facteur doivent être suffisamment élevé pour que les valeurs de priorité diffèrent.

• Une priorité est assignée à chaque partition
• Poids : 30000
• La valeur ne varie pas au cours du temps
• Voir l'article partitions pour connaître les valeurs attribuées

• Ce facteur est calculé en fonction de l'utilisation réelle par un usager et de la proportion de ressources qui lui a été attribuée
• Poids : 70000
• Les ressources mesurées sont uniquement le temps CPU
• La valeur varie en fonction du temps et des ressources réellement consommées
• Décrit plus en détail par la suite

L'utilisation de partitions avec des priorités différentes répond à deux objectifs :

• Sur la partie “commune” du cluster, s'assurer que les travaux de courte durée pourront s'exécuter rapidement
• Sur les parties “privatives”, s'assurer que l'équipe ayant financé l'achat disposera de ses ressources lorsqu'elle en a besoin

Le facteur partition est calculé par normalisation de la valeur de priorité de la partition choisie par rapport à la valeur maximale de toutes les partitions.

• Sur la partie “commune” du cluster, la politique retenue est de donner une forte priorité aux jobs rapides, une priorité moyenne aux jobs “normaux” (moins de 48H), et une priorité faible qux jobs “longs” (durée maximale : 30 jours)
• La priorisation est construite par l'utilisation de partitions différentes
  • qui se chevauchent (contiennent les mêmes nœuds)
  • avec des priorités différentes
• Le mécanisme de pré-emption (par suspension des jobs) est déclenché pour libérer de la place pour les jobs d'une partition sur l'autre

• Certaines parties du cluster ont été financée par un laboratoire particulier
• Une partition à accès restreint matérialise ces équipements
• La priorité de cette partition est extrêmement élevée
• L'accès à cette partition est restreinte au labo (via un account, ou ligne de crédit, spécifique)

• Comme nous l'avons vu, le fair-share est un des deux facteurs de calcul de la priorité
• Il est basé sur la mesure l'activité passée (temps CPU consommé), via le mécanisme d'accounting (comptabilité) de slurm
• Le calcul du facteur est fait en comparaison
  • à une part donnée (share)
  • à l'utilisation des autres usagers
• Comme tout facteur, la valeur calculée sera un réel dans [0; 1.0]
  • 0.5 : signifie que l'utilisateur a déjà consommé exactement ce qui lui a été alloué
  • Une valeur inférieure (resp. supérieure) à 0.5 indique que l'utilisateur a déjà consommé moins (resp. plus) que ce qui lui a été alloué

• Pour comprendre le fair-share, il faut au préalable comprendre l'accounting
• La mesure des ressources consommées par un job, pour un utilisateur (user) sera imputé sur un account, une ligne de crédit
• Les account sont organisés sous une forme hiérarchique : organisme / institut / labo par exemple
• On affecte un nombre de parts (share) à chaque account, représentant la proportion de ressources allouées à cet account en comparaison des autres de même niveau

• Sous chaque institut, un autre account existe, par laboratoire
• Chacun dispose du même poids relatif

• Tous les utilisateurs d'un account (labo dans notre cas) ont la même part
• Donc au sein d'un labo, un utilisateur ayant plus consommé de ressources qu'un autre sera moins prioritaire

• L'utilisation passée est atténuée au fil du temps
• La demi vie est fixée à : 90 jours
• Pour atteindre la part d'utilisation attribuée chaque account, l'usage d'un utilisateur est corrigé par l'utilisation des autres utilisateurs et des autres comptes (usage effectif)
• Autrement dit, la consommation de ressources par les autres membres du laboratoire, et par les autres laboratoires de l'institut, va affecter la priorité d'un utilisateur

• La commande sreport affiche les valeurs d'utilisation enregistrées
• Utilisez la commande sreport-summary pour une vue synthétique sur 30 jours

• La commande sshare affiche les informations sur les parts (share) allouées, l'utilisation mesurée, effective et la valeur du facteur de fair-share
• Avec l'option -u USER : affich les infos pour un utilisateur