``` sbatch: error: Batch job submission failed: Invalid qos specification ```
Cette page centralise les informations techniques, les configurations, tout ce qui est spécifique au cluster de calcul HPC IO. Cette page est votre référence, elle est maintenue prioritairement par rapport aux autres documentations de ce wiki. Elle prévot donc sur toutes les autres les informations que vous pourriez trouver.
| Certaines informations, notamment les limites et politiques, peuvent évoluer. Consultez régulièrement cette page et les annonces des administrateurs. En cas de doute, contactez le support en ouvrant un ticket https://isdm-tickets.meso.umontpellier.fr/. |
Informations pour vous connecter et interagir avec les différents points d’entrée du cluster.
io-loginRôle : Votre point d’entrée principal pour vous connecter au cluster, compiler votre code, éditer des fichiers, soumettre et gérer vos jobs SLURM, et effectuer des tâches légères.
FQDN (Nom de domaine complet) : io-login.meso.umontpellier.fr
cette adresse générique vous envoie sur les 2 "vrais" noeuds de login :
, io-login-01.meso.umontpellier.fr 194.199.232.101
, io-login-02.meso.umontpellier.fr 194.199.232.102
Rôle : Nœuds avec des capacités graphiques améliorées pour la visualisation interactive de données ou l’utilisation d’applications graphiques.
Impact : Permet d’éviter de surcharger les nœuds de connexion avec des applications graphiques lourdes. Peut nécessiter une réservation ou une connexion spécifique.
Utilité : Analyse post-traitement, débogage visuel.
Comment s’y connecter :
Peut nécessiter SSH avec X11 forwarding (ssh -X ou ssh -Y).
Peut être accessible via un portail web ou un client VNC/X2Go.
FQDN/IP : io-login.meso.umontpellier.fr
Rôle : Interface web permettant d’accéder au cluster, de gérer les fichiers, de soumettre des jobs, d’ouvrir des terminaux ou des applications interactives (Jupyter, RStudio, Bureau distant…) directement depuis un navigateur.
Impact : Simplifie l’accès pour certains utilisateurs ou pour des tâches spécifiques.
Utilité : Accès simplifié, lancement d’applications interactives sans configuration complexe.
Comment s’y connecter : Via une URL.
authentification avec votre login/mot de passe
MPI : il y a actuellement des soucis avec MPI; En fonction de l’usage des cas d’usage de MPI, les performances ne sont parfois pas au rendez-vous. Le dossier est en cours de qualification
VS code : l’environnement actuel ne permet pas d’utiliser le module remote de VS code.
Détails sur l’ordonnanceur SLURM, ses partitions et ses limites. Tout ce qui est utilise à la soumission de jobs.
Version update :
20250401 : v23
20250527 : v24.11
Rôle : Les partitions regroupent des nœuds de calcul (parfois homogènes, parfois hétérogènes) et définissent des politiques d’accès (limites de temps, taille de job, utilisateurs autorisés…). Choisir la bonne partition est essentiel.
Impact : Détermine sur quels types de nœuds votre job peut tourner, combien de temps il peut tourner, et potentiellement sa priorité ou son temps d’attente.
Utilité : Permet d’adapter votre soumission aux besoins du calcul (test rapide vs. longue production, CPU vs. GPU…).
Comment trouver l’info :
Lister toutes les partitions et leur état : ou (mieux) sinfo sinfo -s
Détails complets d’une partition (limites, nœuds associés) : (remplacer sinfo -p <nom_partition> -le <nom_partition>)
Voir les partitions accessibles par votre QOS par défaut : (peut nécessiter des droits) ou consulter la documentation.sacctmgr show qos format=DefaultPartition
| Nom Partition | Description / Usage Typique | Accès (Groupes/Projets) | Nb de coeurs | Temps par défaut (DefaultTime) & Temps maximum (MaxWall) | Caractéristiques Notables / Nœuds |
|---|---|---|---|---|---|
|
Consommation d’heures CPU à la demande |
Tous utilisateurs à la demande (dont les utilisateurs de tests demo*) |
2400 |
|
CPU standard ( |
|
Utilisateurs de l’offre dédiée |
Tous utilisateurs de l’offre dédiée (par projet/équipe/account) |
~7000 |
|
CPU standard ( |
Partition par Défaut : cpu n’existe plus ! La partition utilisée si vous ne spécifiez pas --partition dans votre script est désormais .cpu-ondemand
dedicated : En conséquence, si vous avez un account de type dedicated-*@* , il faut penser à spécifier la partition à la soumission cpu-dedicated ! Sinon, vous aurez l’erreur suivante :
``` sbatch: error: Batch job submission failed: Invalid qos specification ```
Comment la trouver : (la ligne avec l’astérisque).sinfo | grep "*"
GPU : les partitions gpu-dedicated et gpu-ondemand existent de la même manière que cpu-dedicated et cpu-ondemand et proposent 4 carte Nvidia H100 par noeud.
Les informations sur les GPUs ici[https://docs.meso.umontpellier.fr/fr/HPC/CLUSTER/slurm-intermediate#_informations_sur_les_gpu].
Des limites s’appliquent souvent à l’ensemble des jobs d’un utilisateur ou d’un groupe, indépendamment de la partition.
Nombre Max de Jobs Soumis (Pending + Running) :
Rôle : Évite la saturation de l’ordonnanceur par un trop grand nombre de jobs.
Impact : Si vous dépassez cette limite, sbatch échouera avec une erreur (ex: Job submission violated association limit).
Limite : `no limit` jobs par utilisateur.
Comment trouver l’info : .sacctmgr show assoc user=$(whoami) format=MaxSubmitJobsPerUser
Nombre Max de Jobs en Exécution (Running) :
Rôle : Assure un partage équitable des ressources en cours d’utilisation.
Impact : Vos jobs resteront en attente (Pending) même si des ressources sont libres si vous avez déjà atteint cette limite.
Limite : `no limit` jobs RUNNING par utilisateur.
Comment trouver l’info : .sacctmgr show assoc user=$(whoami) format=MaxJobsPerUser
Nombre Max de CPUs/GPUs Utilisés Simultanément :
Rôle : Limite plus fine sur la quantité de ressources matérielles qu’un utilisateur/groupe peut monopoliser.
Impact : Vos jobs resteront en Pending (raison AssocMaxCpuLimit, AssocGrpGRESLimit…) si la limite est atteinte.
Limite : CPU: `no limit` cœurs par utilisateur. GPU: `no limit` GPUs par utilisateur.
Comment trouver l’info : (chercher sacctmgr show assoc user=$(whoami) format=MaxTresPerUser cpu=, gres/gpu=).
Valeurs appliquées si vous ne les spécifiez pas dans votre script, et limites infranchissables.
Temps d’Exécution (Walltime) :
Rôle : Durée maximale pendant laquelle un job peut tourner.
Impact : Si le job dépasse cette limite, SLURM le tue (TIMEOUT).
Utilité : Essentiel pour que les ressources se libèrent. Toujours spécifier --time dans vos scripts !
Valeur par Défaut (si non spécifié) : 7-0:0:0 soit 7 jours en global, mais dépend de la QoS et de la partition utilisée.
[IMPORTANT] ==== Si vous ne spécifiez de temps maximum alors votre job sera probablement tué (dès qu'il dépassera les 7 jours, voir moins selon les qos & partitions : soit 1 heure par exemple sur `ondemand-short`.) L'ordonnanceur doit en effet connaître les limites maximales à allouer aux jobs afin de pouvoir plannifier les futurs jobs. ====
Limite Max : Dépend de la partition (voir tableau ci-dessus).
Comment trouver l’info : Défaut : (pas toujours défini globalement), ou limite de la partition par défaut (scontrol show config | grep DefMemPerCPU sinfo -p partition_defaut -lLe). Max : Limite de la partition choisie (sinfo -p …).
Mémoire (RAM) :
Rôle : Quantité de mémoire vive allouée au job.
Impact : Si le job dépasse la mémoire allouée, SLURM le tue (OUT_OF_MEMORY).
Utilité : Spécifier assez de mémoire est vital. Utilisez --mem=<taille> (ex: 10G) ou `--mem-per-cpu=<taille> (ex: 2G).
Valeur par Défaut (si non spécifié) : 2G par cœur CPU demandé (si --mem-per-cpu ou --mem non spécifié et que la config Slurm DefMemPerCPU est définie). TRÈS IMPORTANT : Ce défaut est souvent trop bas !
[IMPORTANT] ==== Si vous ne spécifiez a mémoire utilisée avec `--mem`, alors votre job sera probablement tué (dès qu'il dépasse les 2Go de RAM) ====
Limite Max : Généralement la mémoire totale du nœud le moins bien doté de la partition, ou une limite par cœur définie par l’admin. Ex: `1500G` sur cpu et cpu_short , `~3.0T` sur highmem.
Comment trouver l’info : Défaut : scontrol show config | grep DefMemPerCPU ou DefMemPerNode. Max : sinfo -p <partition> -o "%m %N" ou scontrol show node <nodename> | grep RealMemory.
Nombre de Coeurs CPU par Tâche (--cpus-per-task) :
Valeur par Défaut : 1.
Limite Max : Nombre total de cœurs sur un nœud (ex: `188`).
Nombre de Tâches (--ntasks) :
Valeur par Défaut : 1.
Limite Max : Dépend des limites de la partition et des limites globales par utilisateur.
Rôle : Permet aux administrateurs de définir des ensembles de limites (temps, nombre de jobs, ressources max) et/ou de poids de priorité différents pour certains utilisateurs ou groupes.
Impact : Peut vous donner accès à des limites plus élevées, une priorité accrue, ou au contraire vous restreindre.
Utilité : Utiliser une QOS spécifique si vous appartenez à un projet prioritaire, ou pour des besoins spécifiques (ex: QOS "long" pour jobs > 5 jours).
Comment trouver l’info :
Quelles QOS existent ? .sacctmgr show qos format=Name%30,Priority,MaxWall,MaxTRESPerUser
Quelle est ma QOS par défaut / Quelles sont mes QOS accessibles ? sacctmgr show assoc user=$(whoami) format=User,Account%30,DefaultQOS%30,QOS%75 ("%<N>" permet de définir la largeur de la colonne associée).
QOS Disponibles : `normal` (défaut), `long`, `highprio` (sur demande justifiée),
Comment utiliser : #SBATCH --qos=<nom_qos>
Pour lister les QOS déjà présentes :
sacctmgr list qos format=name%20,priority,maxwall,flags,grptres%25Name |
Priority |
MaxWall |
Flags |
GrpTRES |
cpu-ondemand |
0 |
cpu=2400,mem=19661000M |
||
smp-ondemand |
0 |
cpu=112 |
||
gpu-ondemand |
0 |
cpu=192 |
||
ondemand-short |
1 |
01:00:00 |
cpu=2400,mem=19661000M |
|
dedicated |
100 |
|||
debug |
10 |
00:15:00 |
||
cpu-ondemand-long |
1 |
120-00:00:00 |
OverPartQOS |
cpu=1000,mem=8000G |
smp-ondemand-long |
1 |
OverPartQOS |
cpu=112 |
|
gpu-ondemand-long |
1 |
OverPartQOS |
cpu=192 |
|
visu-ondemand-long |
1 |
OverPartQOS |
cpu=192 |
|
demo-ondemand |
0 |
OverPartQOS |
cpu=100 |
|
visu-ondemand |
0 |
cpu=192 |
Le flag OverPartQOS indique que la priorité de la partition sera écrasée par la QOS utilisée par le job.
Voir page dédiée pour les accounts et QOS.
Rôle : Permettent aux administrateurs (ou parfois aux utilisateurs via une procédure) de réserver un ensemble de nœuds pour une période donnée, pour un usage spécifique (maintenance, cours, projet urgent…).
Impact : Les nœuds réservés ne sont pas disponibles pour les jobs classiques. Votre job peut devoir attendre la fin d’une réservation. Si vous avez accès à une réservation, vos jobs peuvent démarrer immédiatement dessus.
Utilité : Assurer la disponibilité des ressources pour un événement planifié.
Comment trouver l’info : scontrol show reservation
Comment utiliser : #SBATCH --reservation=<nom_reservation>
Comprendre où stocker vos données et quelles sont les limites est fondamental.
| Nom / Point de Montage | Usage Principal | Sauvegardé ? (Snapshot/Backup) | Quota Espace | Quota Fichiers (Inodes) | Caractéristiques Notables |
|---|---|---|---|---|---|
|
Répertoire personnel. Code source, scripts, petits fichiers de conf/résultats, logiciels perso (conda envs…). Pas pour les I/O intensifs des jobs ! |
Snapshots (3/J, 1/semaine durant 4 semaines) |
`180 Go` (soft) / `180 Go` (Hard) |
`xxxxxx` (Soft) / `250 000` (Hard) |
NFS, accès depuis tous les nœuds. Performances moyennes. Limité en taille. |
PERSO : |
Espace de travail temporaire pour les données des jobs en cours. I/O intensifs, gros fichiers temporaires/résultats intermédiaires. NON SAUVEGARDÉ ! PURGE fichiers non accédés depuis 2 mois ! |
NON |
partagé, limite `1000 To` |
`xxxxxxx` |
Système de fichiers parallèle (Weka). Hautes performances. Purge automatique des fichiers non accédés depuis `60` jours ! |
|
Espace partagé pour un projet/groupe. Données communes à conserver longtemps. |
Snapshots (3/J, 1/semaine durant 4 semaines) + réplication pour les projet dit |
Variable selon projet (`de 1To à plusieurs Po`) |
Variable |
parallèle NFS . Accès contrôlé par groupe. Accès en lecture seulement depuis tous les nœuds. Performances moyennes. Limité en taille. |
Rôle : Limiter l’espace disque (en To) et/ou le nombre de fichiers (inodes) qu’un utilisateur ou un groupe peut utiliser sur un système de fichiers.
Impact : Si vous dépassez un quota "soft", vous avez une période de grâce pour nettoyer. Si vous dépassez un quota "hard", vous ne pouvez plus écrire de données ou créer de fichiers. Vos jobs peuvent échouer !
Utilité : Assure un partage équitable des ressources de stockage coûteuses. Vous incite à nettoyer vos anciens fichiers.
Comment trouver l’info :
en construction !!
Type : Weka
Purge Automatique :
Rôle : Libérer de l’espace sur le stockage temporaire.
Impact : Les fichiers non utilisés sont supprimés !
Politique Locale : Fichiers sur non accédés (lus ou modifiés) depuis plus de `60` jours sont automatiquement supprimés./scratch
Comment vérifier l’âge : (affiche la date du dernier accès).ls -lu
Le scratch N’EST PAS un espace de stockage ou d’archivage ! Copiez vos résultats importants vers votre $HOME, un de vos Workdir ou transferrez les sur une serveur externe.
|
Comment accéder aux compilateurs, bibliothèques et applications.
Rôle : Outil principal pour charger/décharger les versions des logiciels installés centralement. Modifie votre environnement (PATH, LD_LIBRARY_PATH…) dynamiquement.
Commandes Clés : module avail, module spider <nom>, module load <nom>/<version>, module list, module purge.
Toolchains : Les logiciels sont souvent groupés par "toolchain" (ensemble compilateur/MPI/libs). Ex: foss/YYYYa, intel/YYYYb. Charger une application nécessite souvent de charger (ou que Lmod charge automatiquement) la toolchain correspondante.
Comment trouver l’info : Utiliser module spider pour voir les versions, dépendances et comment charger un module spécifique.
Module(s) par Défaut : Aucun module chargé par défaut. Utiliser module list après connexion pour voir.
Version Lmod : module --version
Rôle : Permet aux utilisateurs de créer leurs propres environnements isolés avec des paquets spécifiques (surtout Python/R et leurs dépendances), souvent via le canal conda-forge.
Disponibilité : module miniforge3 est fourni.
Configuration Recommandée : Priorité strict, canaux conda-forge, bioconda (si besoin).
Interaction avec Modules : Éviter de mélanger module load et conda activate pour les mêmes bibliothèques (ex: charger un MPI via module et un autre via Conda). Privilégier l’un ou l’autre pour un environnement donné. Parfois, il faut charger un module GCC avant de créer/utiliser un environnement Conda qui compile du code.
Rôle : Fournir des environnements logiciels complets, portables et reproductibles sous forme d’images (.sif). Utile pour des logiciels complexes, des workflows spécifiques ou pour assurer une compatibilité exacte avec un environnement externe.
Disponibilité : Commande apptainer (ou singularity) disponible.
Utilisation : apptainer pull …, apptainer exec …, apptainer shell ….
Accès GPU : Utiliser l’option --nv.
Intégration Slurm : Lancer apptainer exec … dans le script sbatch.
Rôle : Quelques outils de base peuvent être disponibles directement sans module (ex: git, vim, make…).
Comment trouver l’info : Essayer la commande. Utiliser which <commande>.
Guix fait partie des logiciels installés globalement sur le système. Un fichier dans /etc/profile.d/guix.sh est sourcé lorsque vous vous connectez et un lien vers un binaire est présent dans /usr/local/bin/guix.
| d’autres bonnes pratique plus générales se trouve sur la page bonne pratique du cluster. |
Respecter ces règles assure un fonctionnement fluide pour tous.
Usage du Nœud de Connexion : Strictement interdit d’y lancer des calculs. Utilisez sbatch / srun / salloc.
Soumission de Jobs :
Toujours spécifier --time, --mem (ou --mem-per-cpu), et une --partition adaptée.
Ne pas demander plus de ressources que nécessaire (CPU, mémoire, temps). Utilisez sacct et seff pour estimer.
Utiliser des noms de jobs explicites (--job-name).
Ne pas soumettre des milliers de jobs très courts si un Job Array (--array) est possible.
Gestion des Données :
Utiliser le scratch pour les données temporaires/volumineuses des jobs.
Nettoyer le scratch régulièrement..
Ne pas saturer $HOME.
Fairshare : Soyez conscient que l’utilisation intensive réduit temporairement votre priorité. Planifiez vos grosses campagnes de calcul.
Sécurité : Ne partagez pas votre mot de passe. Gérez les permissions de vos fichiers correctement (chmod).
Documentation du Cluster : https://docs.meso.umontpellier.fr/ ← LISEZ-LA !
Système de Tickets / Support : https://isdm-tickets.meso.umontpellier.fr/ Pour les problèmes techniques, …
Formation : https://isdm.umontpellier.fr/la-clinique-des-donnees/
Utilisateurs Référents / Collègues : Discutez avec les utilisateurs expérimentés de votre laboratoire/équipe ou le référent calcul de votre unité.
Commandes d’Aide :
man <commande> (ex: man sbatch, man rsync)
module help ou module help <nom_module>
conda --help ou conda <sous-commande> --help
apptainer help ou apptainer help <sous-commande>