Partitions CPU
Les partitions CPU disponibles
Tous les projets DARI (allocations dynamiques (AD), allocations régulières (AR), ...) ayant des heures CPU ont à leur disposition des partitions Slurm définies sur Jean Zay :
- La partition cpu_p1
est automatiquement utilisée si aucune partition n'est précisée, pour tous les travaux demandant
des heures CPU.
Par défaut, le temps d'exécution est de 10 minutes et il ne peut pas dépasser 100 heures (soit--time=HH:MM:SS≤ 100:00:00, cf. ci-dessous). - La partition prepost permet de
lancer un travail sur l'un des nœuds pré/post-traitement de Jean Zay (
jean-zay-pp), sur lesquels les heures de calcul ne sont pas déduites de votre allocation.
Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit--time=HH:MM:SS≤ 20:00:00, cf. ci-dessous). - La partition visu permet de lancer
un travail sur l'un des nœuds de visualisation de Jean Zay (
jean-zay-visu), sur lesquels les heures de calcul ne sont pas déduites de votre allocation.
Par défaut, le temps d'exécution est de 10 minutes et il ne peut dépasser 4 heures (soit--time=HH:MM:SS≤ 4:00:00, ci-dessous). - La partition archive est dédiée
aux commandes permettant de gérer les données (copies ou déplacements de fichiers, création d'archives) :
les heures de calcul ne sont pas déduites de votre allocation.
Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit--time=HH:MM:SS≤ 20:00:00, cf. ci-dessous). - La partition compil est dédiée
aux compilations des codes et bibliothèques qui ne peuvent se faire sur la frontale car elles
requièrent trop de temps ressources (temps CPU ou mémoire) : les heures de calcul ne sont pas
déduites de votre allocation.
Par défaut, le temps d'exécution est de 2 heures et il ne peut dépasser 20 heures (soit--time=HH:MM:SS≤ 20:00:00, cf. ci-dessous). - La partition compil_h100 est dédiée
aux compilations des codes et bibliothèques qui s'exécuteront sur la partition Eviden H100
(gpu_p6).
Elle contient un nœud équipé d'un processeur Intel identique à ceux de la partition Eviden H100.
Elle a les mêmes caractéristiques d'accès que la partition
compil.
Les caractéristiques techniques de chaque partition sont présentées ici.
Les limites de temps par défaut des partitions sont délibérément basses. Pour des exécutions longues, vous devez spécifier une limite de temps d'exécution, qui doit rester inférieure au maximum autorisé pour la partition et la QoS utilisées (voir ci-dessous). Vous devez alors utiliser :
- soit la directive Slurm
#SBATCH --time=HH:MM:SSdans votre travail, - soit l'option
--time=HH:MM:SSdes commandessbatch,sallocousrun.
La partition cpu_p1 étant la partition utilisée par défaut, elle
n'a pas besoin d'être demandée. Par contre, toutes les autres doivent
être spécifiées explicitement pour être utilisées.
Par exemple, pour la partition prepost, vous pouvez utiliser :
- soit la directive Slurm
#SBATCH --partition=prepostdans votre travail, - soit l'option
--partition=prepostdes commandessbatch,sallocousrun.
Tout travail demandant plus d'un nœud s'exécute en mode exclusif : les nœuds ne sont pas partagés. L'utilisation d'une partie d'un nœud entraîne alors la facturation de la totalité du nœud. Par exemple, la réservation de 41 cœurs (soient 1 nœud + 1 cœur) entraîne la facturation des 80 cœurs (soit 2 nœuds). Par contre, la totalité de la mémoire des nœuds réservés est alors disponible (de l'ordre de 160 Go utiles par nœud).
Les QoS CPU disponibles
Pour chaque travail soumis dans la partition cpu_p1, vous pouvez spécifier une QoS (Quality of Service) qui va déterminer les limites et la priorité de votre travail :
-
la QoS par défaut pour tous les travaux CPU : qos_cpu-t3
- durée maximale : 20h00 de temps Elapsed,
- 10240 cœurs physiques (256 nœuds) maximum par travail,
- 20480 cœurs physiques (512 nœuds) maximum par utilisateur (tous projets confondus),
- 20480 cœurs physiques (512 nœuds) maximum par projet (tous utilisateurs confondus).
-
une QoS pour des exécutions plus longues et qui doit être spécifiée pour être utilisée (cf. ci-dessous) : qos_cpu-t4
- durée maximale : 100h00 de temps Elapsed,
- 160 cœurs physiques (4 nœuds) maximum par travail,
- 640 cœurs physiques (16 nœuds) par utilisateur (tous projets confondus),
- 640 cœurs physiques (16 nœuds) maximum par projet (tous utilisateurs confondus),
- 5120 cœurs physiques (128 nœuds) maximum pour l'ensemble des travaux demandant cette QoS.
-
une QoS réservée uniquement à des exécutions brèves effectuées dans le cadre de développements des codes ou de tests d'exécutions et qui doit être spécifiée pour être utilisée (cf. ci-dessous) : qos_cpu-dev
- un maximum de 10 travaux (en cours d'exécution ou en attente) simultanément par utilisateur,
- durée maximale : 2h00 de temps Elapsed,
- 5120 cœurs physiques (128 nœuds) maximum par travail,
- 5120 cœurs physiques (128 nœuds) maximum par utilisateur (tous projets confondus),
- 5120 cœurs physiques (128 nœuds) maximum par projet (tous utilisateurs confondus),
- 10240 cœurs physiques (256 nœuds) maximum pour l'ensemble des travaux demandant cette QoS.
Pour spécifier une QoS différente du défaut, vous pouvez au choix :
- utiliser la directive Slurm
#SBATCH --qos=qos_cpu-devdans votre travail, par exemple, - ou spécifier l'option
--qos=qos_cpu-devaux commandessbatch,sallocousrun.
Tableau récapitulatif des limites sur les QoS CPU
| QoS | Limite en temps | Limite en ressource par travail | Limite par utilisateur (tous projets confondus) | Limite par projet (tous utilisateurs confondus) | Limite par QoS |
|---|---|---|---|---|---|
| qos_cpu‑t3 (défaut) | 20h | 10240 cœurs physiques (256 nœuds) | 20480 cœurs physiques (512 nœuds) | 20480 cœurs physiques (512 nœuds) | |
| qos_cpu‑t4 | 100h | 160 cœurs physiques (4 nœuds) | 640 cœurs physiques (16 nœuds) | 640 cœurs physiques (16 nœuds) | 5120 cœurs physiques (128 nœuds) |
| qos_cpu‑dev | 2h | 5120 cœurs physiques (128 nœuds) | 5120 cœurs physiques (128 nœuds), 10 travaux maximum (en cours d'exécution ou en attente) simultanément | 5120 cœurs physiques (128 nœuds) | 10240 cœurs physiques (256 nœuds) |