Aller au contenu principal

Choisir ses ressources

Une demande de ressources bien dimensionnée améliore le temps de démarrage du job, l'utilisation du cluster et la reproductibilité des calculs.

Avant de soumettre un job, déterminez :

  • le type d'exécution : interactive ou batch ;
  • la partition ;
  • le nombre de tâches ;
  • le nombre de CPU par tâche ;
  • la mémoire ;
  • le nombre de GPU, si nécessaire ;
  • la durée maximale ;
  • l'espace de stockage à utiliser.

Méthode recommandée​

  1. Identifiez le profil de votre application.
  2. Commencez par un test court sur debug si cela est possible.
  3. Mesurez le temps d'exécution et la consommation mémoire.
  4. Vérifiez si le programme utilise réellement plusieurs CPU ou un GPU.
  5. Ajustez les ressources demandées.
  6. Passez à un job batch pour la production.

Consultez Ressources de calcul et Partitions.

Choisir le type de job​

BesoinType recommandé
Vérifier une installation ou une commandeSession interactive courte
Développer et déboguerSession interactive avec srun ou Open OnDemand
Calcul long et reproductibleJob batch avec sbatch
Campagne de nombreux calculsJobs batch avec dépendances ou tableau de jobs
Interface graphiqueSession TurboVNC sur visu

Choisir une partition​

Utilisez généralement :

  • debug pour les tests rapides ;
  • std pour les calculs CPU courants ;
  • gpu pour les applications qui utilisent un GPU ;
  • visu pour la visualisation et les interfaces graphiques.

Les noms, limites et règles peuvent évoluer. Vérifiez les informations disponibles avec :

sinfo

Choisir les CPU​

Une tâche multithreadée​

Si un seul processus utilise plusieurs threads, demandez une tâche et plusieurs CPU par tâche :

#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8

Cette configuration convient généralement aux programmes OpenMP ou aux logiciels qui contrôlent eux-mêmes le nombre de threads.

Plusieurs tâches​

Si le programme utilise plusieurs processus, demandez plusieurs tâches :

#SBATCH --ntasks=8
#SBATCH --cpus-per-task=1

Cette configuration peut convenir à certains programmes MPI ou à des workflows composés de processus indépendants.

Ne pas surdimensionner​

Demander 32 CPU à un programme séquentiel ne le rend pas automatiquement plus rapide. Commencez petit, mesurez les performances et augmentez la demande uniquement si le programme exploite les ressources supplémentaires.

Choisir la mémoire​

La mémoire doit couvrir les données chargées et les besoins des processus.

Vous pouvez demander une quantité totale :

#SBATCH --mem=16G

Ou une quantité par CPU :

#SBATCH --mem-per-cpu=2G

N'utilisez pas simultanément --mem et --mem-per-cpu sans connaître le comportement attendu de la configuration SLURM locale.

Un manque de mémoire peut provoquer l'arrêt du job. Une demande excessive peut augmenter le temps d'attente.

Choisir un GPU​

Demandez un GPU uniquement si le logiciel est compatible et si le calcul l'utilise réellement.

Exemple générique :

#SBATCH --partition=gpu
#SBATCH --gres=gpu:1
#SBATCH --cpus-per-task=4
#SBATCH --mem=16G

Vérifiez le GPU attribué :

nvidia-smi

Prenez en compte :

  • la mémoire GPU nécessaire ;
  • la compatibilité CUDA ou des bibliothèques utilisées ;
  • le nombre de CPU nécessaires pour alimenter le GPU ;
  • le nombre de GPU réellement exploités par le programme.

Les options exactes peuvent varier selon la configuration du cluster.

Choisir la durée​

Demandez une durée légèrement supérieure au temps réellement nécessaire, sans ajouter une marge excessive.

Exemple : si un test dure environ 20 minutes, demandez 30 minutes plutôt que plusieurs heures.

Une durée réaliste :

  • facilite la planification ;
  • limite la réservation inutile de ressources ;
  • réduit le risque de dépasser une limite de partition ;
  • permet d'améliorer les estimations lors des exécutions suivantes.

Tester avant la production​

Effectuez un test sur un jeu de données réduit :

srun \
--partition=debug \
--ntasks=1 \
--cpus-per-task=2 \
--mem=4G \
--time=00:10:00 \
--pty bash

Mesurez ensuite le temps et la mémoire du job. Pour un job terminé :

sacct -j <job_id> --format=JobID,State,Elapsed,MaxRSS,AllocTRES

Exemple de script batch​

#!/bin/bash
#SBATCH --job-name=mon-calcul
#SBATCH --partition=std
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=8G
#SBATCH --time=01:00:00
#SBATCH --output=logs/%x-%j.out
#SBATCH --error=logs/%x-%j.err

set -euo pipefail

mkdir -p logs
module load <module>

python script.py

Remplacez <module> par un module disponible et adaptez les ressources au programme.

Soumettez le script avec :

sbatch mon-calcul.slurm

Vérifier l'utilisation réelle​

Après l'exécution, comparez les ressources demandées aux ressources consommées :

sacct -j <job_id> \
--format=JobID,State,Elapsed,AllocCPUS,MaxRSS,AllocTRES

Si le job utilise peu de CPU ou de mémoire par rapport à la demande, réduisez les ressources lors de la prochaine exécution. Si le job atteint une limite, augmentez progressivement la ressource concernée.

Résumé pratique​

ProfilPremière demande conseillée
Test de commandedebug, 1 tâche, 1–2 CPU, peu de mémoire, durée courte
Code multithreadé1 tâche, plusieurs cpus-per-task, mémoire mesurée
Programme MPIPlusieurs tâches, selon la documentation du logiciel
Calcul GPUPartition gpu, GPU compatible, CPU et mémoire adaptés
VisualisationPartition visu, session TurboVNC
ProductionJob batch, durée estimée et ressources mesurées
astuce

Développer puis produire

Utilisez une session interactive courte pour valider votre code et vos paramètres. Une fois le workflow vérifié, utilisez un script batch pour le calcul de production.

Pages associées​