Mode batch SLURM

SLURM remplace SGE

(raisons du changement)

Documentation

  • http://slurm.schedmd.com/documentat... contient la documentation SLURM (Simple Linux Utility for Resource Management) version 2.6 installée sur la GMPCS. SLURM permet la soumission en mode traitement par lots (batch) et est le successeur de SGE ;
  • le fichier read me que nous avons écrit contient un mode d’emploi simplifié avec une comparaison SLURM <=> SGE

Scripts SLURM

Scripts de SLURM :

lignecontenucommentaires
1 # !/bin/bash Lecture de $HOME/.bashrc
2 D’abord les directives SLURM
3 #SBATCH directive 1 (#SBATCH en début de ligne)
4 #SBATCH directive 2 (#SBATCH en début de ligne)
5 Puis les commandes utilisateur
6 # commentaire (# indique un commentaire)
7 commande 1 (commande shell / exécutable)
8 commande 2 (commande shell / exécutable)

dans la partie "commandes utilisateur" POSITIONNER les variables utilisées à l’exécution :

  • export VARIABLE=valeur

et SYSTEMATIQUEMENT les VERIFIER :

  • echo "VARIABLE = " $VARIABLE

Exemples :

Suivi des jobs

  • suivi graphiques sview ou smap
  • suivi en ligne de commande squeue, squeue -l et sstat
  • arrêt d’un job scancel

Procédure générale

Avant de pouvoir travailler en mode traitement par lots/batch vous devez créer votre environnement de travail, en particulier un exécutable. Deux étapes donc :

  1. En interactif sur le maître créez et testez votre exécutable avec les contraintes suivantes :
    • < 5 minutes de temps de calcul
    • < 32 Go de mémoire vive ;
  2. L’environnement de travail créé, vos calculs sont lancés et gérés par le gestionnaire batch SLURM. On appelle jobs vos programmes de calculs pris en charge par SLURM. Vous soumettez vos jobs en ligne de commande via un script de soumission :
  1. Il existe trois types de jobs :
    • les sequential jobs qui correspondent à l’exécution d’un programme séquentiel ;
    • les parametric/array jobs qui consistent en l’exécution en parallèle de plusieurs instances d’un même programme. Ces instances sont complètement indépendantes, seules les données utilisées sont différentes. La dernière ligne des commandes utilisateur lance un programme "balai/sweep" avec —dependency=singleton qui ne s’exécutera qu’après que tous les calculs sont terminés. Pour limiter le nombre de taches simultanées voici un second type de array jobs exécutant max_array taches simultanément max_times fois. Pendant l’exécution de ce job avec sview vous ne verrez que max_array jobs chacun s’exécutant pendant max_times*le temps d’une tache élémentaire. Attention : si l’indexation de données d’entrée et d’impression est de 1 à max_array*max_times, l’indexation de l’écriture des fichiers sur disque est de -1,1,2, ... max_array*max_times-1 ;
    • les parallel jobs, de type OpenMP ou MPI, qui sont un ensemble de tâches exécutées en parallèle et distribuées sur la GMPCS. Les programmes OpenMP sont distribués sur un seul et même noeud alors que les programmes MPI peuvent être distribués sur plusieurs noeuds.

Vous pouvez consulter la correspondance entre les directives de SLURM et SGE dans le rosetta


Documents joints

PDF - 256 ko
PDF - 256 ko
PDF - 61 ko
PDF - 61 ko

RTRA

Annonces

Stage : "Conteneurs dans un environnement HPC"

Rapport de stage de Jiaming HU :

PDF - 1.7 Mo
(mai - août 2017)

Stage : "Machines virtuelles et haute disponibilité"

Rapport de stage de Mahdi HAMMOUCHE :

PDF - 1.2 Mo
(juin - septembre 2016)

Stage : "Grappe de calcul HPC à éléments délocalisés"

Rapport de stage de Brahim BIKI :

PDF - 1.4 Mo
(mai-août 2015)

Stage : "Optimisation des ressources d’un cluster pour le calcul scientifique"

Rapport de stage de Damien Delhay :

PDF - 1.4 Mo
(mai-juillet 2014)

Stage : "Diagonalisation des matrices réelles sur GPU"

Rapport de stage de Kun SONG :

PDF - 803.4 ko
(mai - août 2013)

Stage : "Optimisation du transfert de données entre un CPU et un GPU"

Rapport de stage de Jean YAOKELI :

PDF - 915.4 ko
(mai - août 2012)