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

Références

Critères de calcul

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

Voir les valeurs de priorité

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é

Formule de calcul

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.

Partition

  • 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

Fair-share

  • 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

Priorité des partitions

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.

rapide / normal / cluster

  • 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

Parties privatives du cluster

  • 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)

Fair-share

  • 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é

Account

  • 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

Account niveaux 1 et 2 et poids

partenaires 100 (10%) cistem 1 (50% des partenaires) [5% du total]
ingenomix 1 (50%) [5%]
unilim 900 (90%) XLIM 283 (28,3 %) [25,4%]
IPAM 283 (28,3 %) [25,4%]
GEIST 283 (28,3 %) [25,4%]
SHS 150 (15%) [13,5%]

Account par labo (niveau 3)

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

Share par utilisateur

  • 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

Utilisation passée

  • 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

Consulter l'utilisation comptabilisée

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

Consulter la valeur du fair-share

  • 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