Configuration du gestionnaire de jobs¶
Principe de fonctionnement¶
Sur Vision, PBS (version 20.1) (documentation : PBSUserGuide2020.1 ) est utilisé pour gérer les files d'attente sur l'ensemble de la machine. PbsPro 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 files 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 qsub. Plusieurs types de langages de script peuvent être utilisés (shell unix, perl, python). Les paramètres du script peuvent être soumis directement lors de l'appel de la commande, ou dans le script ::
[homer@thor ~]# cat myscript.sh
#!/bin/sh
#PBS -l walltime=1:00:00
#PBS -N testjob
#PBS -l select=mem:32gb:ncpus=24
#PBS -j oe
./my_application
[homer@vision ~]# qsub myscript.sh
PBS fonctionne pour l'attribution des ressources sur la notion de chunk, correspondant à un ensemble de ressources défini comme une unité. Dans le cas de Vision, la première unité de calcul peut être vue comme une carte mère de la machine. Les demandes d'*unité* de calcul se font par l'option ::
qsub -l select=[N:][chunk specification][+[N:]chunk specification] my_script.pbs
#PBS -l select=[N:][chunk specification][+[N:]chunk specification]
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.
ref : https://forge.univ-poitiers.fr/projects/calculateur-vision/wiki/Architecture_du_calculateur#Cpuset
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.
Files d'attente¶
Le système de gestion des travaux possède plusieurs types files (queue) d'attente:
calcul_big: Pour les jobs relativement courts et demandant des ressources importantes (voir plus loin)calcul_small: Pour les jobs relativement longs et demandant des ressources modéréesgpuq: permet d'accéder aux cartes gpu pour réaliser des traitement intensifs de calculs (4 cartes réservées pour le calcul)visuq: permet d'accéder aux cartes gpu pour réaliser la visualisation déportée (4 cartes réservées pour la visualisation)interq: permet d'utiliser la machine pour des traitements interactifs ne demandant pas de ressources gpu
Limites des jobs¶
Afin d'être éligibles à l'exécution, les jobs doivent satisfaire certaines contraintes (3 max par utilisateur en run quelque soit la file) ;
[homer@vision]$ pbs_queue
=====================================================================================================
Queue Max MaxRun MaxRun MaxQueued MaxQueued Priority Current Running Queued
Walltime /user forall /user forall Jobs Jobs Jobs
=====================================================================================================
workq 50:00:00 3 0 0 0 20 0 0 0
visuq 24:00:00 0 0 0 0 140 0 0 0
gpuq 40:00:00 0 0 0 0 140 0 0 0
default -- 0 0 0 0 - 0 0 0
calcul_small90:00:00 0 0 0 0 80 1 1 0
interq 24:00:00 0 0 0 0 140 0 0 0
calcul_big 48:00:00 0 0 0 0 120 0 0 0
Sorting Jobs policy use : 3*queue_priority+2*eligible_time/3600+custom_prio
Max queued per user : 20
Max run per user : 3
Max cpus per user : 188
Max gpus per user : 4
Walltime la durée maximale du job
visuq: walltime max 24h ; gpu max = 4 ; mem max = 768 Gbgpuq: walltime max 40h ; gpu max = 4 ; mem max = 768 Gbinterq: walltime max 24h ; mem max = 768gbcalcul_small: walltime max 90h ; ncpus max = 48 ; mem max = 1000gbcalcul_big: walltime max 48h ; ncpus max = 168 ; mem max =1.5 To
Détermination de la priorité entre jobs¶
Le calcul de la priorité entre les jobs prend en compte plusieurs facteurs.
Formula¶
Les calculs sont triés en fonction d'une formule prenant en compte la priorité des files, du temps d'attente dans la file ;
Sorting Jobs policy use : 3*queue_priority+2*eligible_time/3600+custom_prio + 50*fairshare_factor
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 Vision, 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.
Starving jobs¶
Quand les jobs sont en attente de ressources pendant un temps "important" (dans notre cas), ils passent dans un mode prioritaire qui va augmenter leurs priorités