Jean Zay : partitions Slurm CPU

Les partitions disponibles

Tous les projets DARI ou Accès Dynamique (AD) 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 c.f. 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 c.f. 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 c.f. 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 cpu : 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 c.f. ci-dessous).

Attention aux limites de temps par défaut des partitions, qui 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. Vous devez alors utiliser :

  • soit la directive Slurm #SBATCH --time=HH:MM:SS dans votre job,
  • soit l'option --time=HH:MM:SS des commandes sbatch, salloc ou srun.

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=prepost dans votre job,
  • soit l'option --partition=prepost des commandes sbatch, salloc ou srun.

Attention : depuis le 11 octobre 2019, tout travail demandant plus d'un nœud tourne en mode exclusif : les nœuds ne sont pas partagés. L'utilisation d'une partie d'un nœud entraine alors la comptabilité de la totalité du nœud. Par exemple, la réservation de 41 cœurs (soient 1 nœud + 1 cœur) entraine la facturation des 80 cœurs (soient 2 nœuds). Par contre, la totalité de la mémoire des nœuds réservés est disponible (de l'ordre de 160 Go utiles par nœud).

Les QoS disponibles

Pour chaque job soumis dans une partition autre que les partitions archive, compil, prepost et visu, vous pouvez spécifier une QoS (Quality of Service) qui va déterminer les limites et la priorité de votre job :

  • la QoS par défaut pour tous les travaux CPU : qos_cpu-t3
    • durée max : 20h00 de temps Elapsed,
    • 20480 cœurs physiques (512 nœuds) maximum par travail,
    • 48000 cœurs physiques (1200 nœuds) maximum par utilisateur (tous projets confondus),
    • 48000 cœurs physiques (1200 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 (c.f. ci-dessous) : qos_cpu-t4
    • durée max : 100h00 de temps Elapsed,
    • 160 cœurs physiques (4 nœuds) maximum par travail,
    • 1280 cœurs physiques (32 nœuds) par utilisateur (tous projets confondus),
    • 1280 cœurs physiques (32 nœuds) maximum par projet (tous utilisateurs confondus),
    • 5120 cœurs physiques (128 nœuds) pour l'ensemble des travaux demandant cette QoS.
  • une QoS pour des exécutions plus brèves et qui doit être spécifiée pour être utilisée (c.f. ci-dessous) : qos_cpu-dev
    • durée max : 2h00 de temps Elapsed,
    • 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),
    • 48000 cœurs physiques (1200 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-dev dans votre job, par exemple,
  • ou spécifier l'option --qos=qos_cpu-dev aux commandes sbatch, salloc ou srun.
Tableau récapitulatif
QoS Limite en temps Limite en ressource
par job par utilisateur (tous
projets confondus)
par projet (tous
utilisateurs confondus)
par QoS
qos_cpu-t3 (défaut) 20h 20480 cœurs physiques
(512 nœuds)
48000 cœurs physiques
(1200 nœuds)
48000 cœurs physiques
(1200 nœuds)
qos_cpu-t4 100h 160 cœurs physiques
(4 nœuds)
1280 cœurs physiques
(32 nœuds)
1280 cœurs physiques
(32 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)
5120 cœurs physiques
(128 nœuds)
48000 cœurs physiques
(1200 nœuds)