Kepler

Le PMCS2I (Pôle de Modélisation et de Calcul en Sciences de l'Ingénieur et de l'Information) de l'Ecole Centrale de Lyon est équipé depuis novembre 2010 d'un serveur de calcul multi-processeurs SGI ALTIX UV 1000 à architecture SMP/NUMA. Ce serveur 64 bits à base de lames ultra-denses à hautes performances offre une puissance totale de 2,042 Tflops.

Cette acquisition a fait l'objet, en juillet 2010 d'un Appel d'Offres Européen avec les contributions du Ministère de l'Enseignement Supérieur et de la Recherche, de la Région Rhône-Alpes, de l'Ecole Centrale de Lyon et des laboratoires CNRS, LMFA et LTDS.

Ce serveur est ouvert à l'ensemble des unités de recherche de l'Ecole, et il peut être ouvert sur demande spécifique pour des projets d'enseignement. Il est installé dans les locaux du Laboratoire de Mécanique des Fluides et d'Acoustique, UMR CNRS 5509 qui en assure la gestion et l'exploitation.

Cette nouvelle plateforme fait partie d'un ensemble d'équipements mis en place dans le cadre de la Fédération Lyonnaise de Modélisation et Sciences Numériques dans les 3 établissements : ENS Lyon, UCB Lyon1, EC Lyon.

CONFIGURATION

Configuration matérielle

Architecture NUMA

Au premier regard, l'utilisateur pourrait voir KEPLER comme une machine à mémoire partagée constituée de 192 cœurs de calcul Xeon Nehalem-EX et 1To de mémoire RAM.

Cependant, dans son ensemble, KEPLER n'est pas une machine de type SMP (Symmetric multiprocessing) où l'accès des coeurs de calcul à la mémoire commune serait uniforme pour tous les coeurs.

En effet, KEPLER est physiquement constitué de 16 lames de calcul, chaque lame ayant sa propre quantité de mémoire (64 Go). C'est grâce à la technologie d'interconnection des lames (NUMAlink) et aux outils SGI que cet ensemble de mémoires physiquement distribuées devient accessible et partagé entre tous les coeurs de calculs et au sein d'un seul système d'opération (un seul système Linux suffit à gérer l’ensemble des ressources processeurs et mémoire).

KEPLER ressemble donc du point de vue matériel à un cluster de calcul (= machine à mémoire distribuée), mais il a les fonctionnalités d'une machine à mémoire partagée (un seul système, adressage à tout l'espace mémoire).

Ainsi, pour un processeur donné, les temps d'accès à une zone mémoire diffèrent suivant la zone mémoire accédée, ce qui signifie que la machine KEPLER est une machine NUMA (pour Non Uniform Memory Access ou Non Uniform Memory Architecture).

Bien qu'on bénéficie d'un réseau NUMAlink très performant (bande passante très rapide - 15 Go/s, faible latence - moins d’une micro-seconde) et de lames ultra-denses à hautes performances, l'utilisateur ne doit pas oublier/ignorer qu'il travaille sur une architecture NUMA et pour qu'il obtienne de bonnes performances sur KEPLER et une reproductibilité des temps CPU, il doit utiliser certaines commandes spécifiques.

Composants matériels

  • 16 lames de calcul soit 192 cœurs et 1 To de mémoire RAM
  • sur chaque lame (= noeud) de calcul : 2 processeurs (à 6 coeurs) Intel Nehalem-EX (Xeon X7542 ) 2,67 GHz, 18 MB cache L3, chaque processeur ayant un accès direct à un espace mémoire de 32 Go.
  • la mémoire (logiquement) partagée 1To est donc la somme de 16 x 2 mémoires physiquement distribuées (de 32 Go)
  • stockage :
    • home directories : baie HP EVA 6350
      • volumétrie actuelle 10 To (extensible)
      • sauvegardés sur bande magnetique (libraire MSL 8096, 4 lecteurs LTO4)
      • accès 4Gb/s (SAN, Fibre Channel)
    • espace /scratch : baie SGI IS 5000
      • volumétrie : 10 To (12 disques x 1To brut)
      • accès 24Gb/s (Infiniband)
      • non sauvegardé
  • Interconnexion NUMAlink5 à 480 Gb/s
  • une machine de d'administration, une console
  • Rack 42U avec refroidissement par eau

Plateforme évolutive jusqu’à 2048 cœurs et 16 To de mémoire et une puissance de 18,6 Tflops.

Configuration logicielle

Système

  • 1 seul OS, SLES (SUSE Linux Entreprise Server)
  • le noyau Linux réside sur la 1ère lame (=12 coeurs et 64 Go RAM)
  • il pilote aussi les 15 autres lames (=180 coeurs) qui forment la partie "calcul intensif" de la machine et qui ne sont accessibles pour l'utilisateur que via le système de queues PBS
  • ne pas lancer des applications lourdes directement dans la partie système au risque de faire "crasher" la machine entière.

Compilateurs

  • Compilateurs INTEL (icc, icpc, ifort)
  • Compilateurs GNU (gcc, g++, gfortran)

Bibliothèques

  • bibliothèque scientifique Intel MKL, NAG, FFTW
  • bibliothèques de parallélisation MPI (MPT, Intel MPI, OpenMPI), PVM, OpenMP

Debuggers, profileurs

  • GNU gdb (applications séquentielles), gprof
  • Intel idb/idbc (applications MPI et OpenMP)
  • Alinea DDT (applications MPI et OpenMP)

Outils d’optimisation et analyse de performances de codes parallèles

  • Intel trace analyser (ITAC)
  • Perfsuite

Logiciels généralistes et/ou spécialisés

  • Utilisation sans restriction : Matlab, Code_Saturne, FreeFEM++, OpenFOAM, ParaView...
  • Utilisation restreinte : ABAQUS, NASTRAN, CRADLE, elsA, FLUX, ...
  • Codes "maison" ou en partenariat : Turb'Flow, Asphodele, Arps, Alesia, DNS3D…

Utilitaires

  • Editeurs : gedit, vi, emacs
  • Visualisation graphique des données : gnuplot
  • Outils de gestion de versions : cvs, svn, git

Gestionnaire de files d’attente

  • il gère la partie "calcul intensif" de la machine, à savoir 15 lames de calcul (180 coeurs, 960 Go)
  • PBSPro

UTILISATION BASIQUE

Création de compte

Remplir le formulaire de demande d’ouverture de compte sur ce site (en choisissant Kepler).

Dans quelque temps, un message vous sera adressé avec vos identifiants de connexion et quelques informations pratiques.

Accès à la machine

Dans ce qui suit hostname est à remplacer par le nom complet de la machine et login est à remplacer par votre identifiant de nom.

Mode terminal standard

  • à partir d’un poste Linux ou MacOS X :

    ssh login@hostname
  • à partir d’un poste Windows, installer un client ssh (par ex. putty)

Mode terminal graphique

  • à partir d’un poste "UNIX-like" (p.ex. Linux ou MacOS X) :

    ssh -X login@hostname
  • à partir d’un poste Windows, installer un serveur X

Depuis ECL

L’accès à ce serveur est ouvert depuis les machines des laboratoires affiliés au Pôle de Modélisation de Calcul de l'ECL (PMCSII) sur le site d'Ecully

Remarque : Le réseau Wifi de l'ECL n'a pas accès direct à la machine. Depuis ce réseau, il est possible de se connecter sur KEPLER, via le VPN ECL (cf. ci-dessous)

Depuis l'extérieur de l'ECL

Depuis l'extérieur du réseau l'ECL, il y a plusieurs possibilités pour d'accéder à la machine :

  • via le VPN de l'ECL. Pour utiliser ce service : https://services.cri.ec-lyon.fr/mobility/vpn/openvpn.php
  • via la passerelle "sshgate" de l'ECL (tous les nouveaux utilisateurs ECL avaient par défaut un compte sur cette machine, ce n'est plus le cas depuis quelque temps - cette machine est censée de disparaître, le VPN ayant vocation à terme de remplacer ce service).

Connexion sur Kepler en deux commandes :

ssh login_sshgate@sshgate.ec-lyon.fr 
ssh login_kepler@kepler.ec-lyon.fr

Connexion sur Kepler en une seule commande :

ssh -oProxyCommand="ssh login_sshgate@sshgate.ec-lyon.fr netcat -w1 kepler.ec-lyon.fr %p" login_kepler@kepler.ec-lyon.fr

ou

ssh -o 'ProxyCommand ssh login_sshgate@sshgate.ec-lyon.fr nc %h %p' login_kepler@kepler.ec-lyon.fr

Transfert de données depuis/vers Kepler

Depuis le réseau ECL

Transfert vers Kepler

scp nom_fichier_source login_kepler@kepler.ec-lyon.fr:Repertoire_destination

Transfert depuis Kepler

scp login_kepler@kepler.ec-lyon.fr:Repertoire_source/fichier_source nom_repertoire_destination

Depuis l'extérieur ECL

Pour ce qui ont un compte sur sshgate ECL.

Transfert d'un fichier en une seule commande :

scp -oProxyCommand="ssh login_sshgate@sshgate.ec-lyon.fr netcat -w1 kepler.ec-lyon.fr %p" nom_fichier_source login_kepler@kepler.ec-lyon.fr:Repertoire_destination

ou

scp  -o 'ProxyCommand ssh login_sshgate@sshgate.ec-lyon.fr nc %h %p'  nom_fichier_source login_kepler@kepler.ec-lyon.fr:Repertoire_destination

Remarques :
- Pour transférer un répertoire, rajouter l'option "-r" après scp.
- pour transférer un fichier/répertoire dans la direction inverse, il suffit d'inverser la source et la destination dans la commande précédente

  • pour les utilisateurs extérieurs à l'ECL (ENSL, UCB Lyon1, Grenoble, ...), il faut d'abord passer par la passerelle du Pôle de Calcul local (PSMN, P2CHPD, CIMENT, ...) qui elle est autorisée à se connecter
  • pour des cas très particuliers et bien argumentés, nous pouvons mettre en place un accès direct

Espaces disque. Quotas. Sauvegardes

Le volume de stockage actuel pour l'ensemble des homes directoires est de 10 To en RAID6. Les quotas utilisateurs sont en place. Ils sont attribués en fonction des besoins des utilisateurs (30 Go à 400 Go). Pour connaître son quota utiliser la commande :

quota -s login

Vous obtenez une réponse du type :

Disk quotas for user monlogin (uid xxxx): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/lxvm/egypte
                   28G    50G    50G           73623       0       0

ce qui signifie que :

  • votre compte se situe sur la partition /egypte
  • vous utilisez actuellement 28 Go d'espace disque
  • votre quota disque sur cette partition est de 50 Go
  • pas de quota sur le nombre de fichiers

Les home directories sont sauvegardés sur bande magnétique toutes les semaines avec une période de rétention d'un mois (une sauvegarde totale mensuelle et des sauvegardes incrémentales les autres semaines du mois) grâce au logiciel Time Navigator et à la librairie HP MSL 8096 (4 lecteurs LTO-4 et 96 emplacements). En cas de pertes de données (p. ex. suppression involontaire), on peut ainsi remonter jusqu'à un mois.

En plus de home directories, les utilisateurs ont accès à l'espace /scratch/USERS à utiliser pendant l’exécution de leurs travaux (l'accès à cet espace est plusieurs fois plus rapide que sur le home directory). Cet espace de travail temporaire, n'est pas sauvegardé. Les données sont donc conservées d’une exécution à une autre, mais supprimées en principe au bout d’un mois de non utilisation. Il revient à l'utilisateur de récupérer les données de cet espace (p. ex. en fin de job) sur son home directory.

Environnement de travail

Environnement et outils disponibles par défaut

Par défaut les comptes utilisent le shell bash.

Actuellement, l'environnement par défaut donne accès aux produits suivants :
- compilateurs GNU (version "système"),
- vi, emacs, gnuplot
- bison, flex, java
- git, fftw3,
- python, matplotlib
- matlab,
- ...

Chargement des outils (commande "module")

Si besoin d'outils spécifiques, l’utilisateur chargera l'environnement pour les outils dont il aura besoin cf ci-dessous.

Par exemple, l’accès aux compilateurs intel et bibliothèques se fait par l’intermédiaire de chargements de modules : intel, ddt, nag, openmpi, mot, ...

  • Pour connaître la liste des modules:

    module avail
  • Pour charger un module:
    module load <nom_du_module>
  • Pour retirer un module de son environnement de travail:
    module unload <nom_du_module>
  • Pour tout effacer :
    module purge
  • Pouravoir la liste des modules déjà chargés :
    module list
  • Pour afficher les modifications apportées aux variables d’environnement après chargement:
    module show <nom_du_module>

Compilation

Plusieurs versions des compilateurs Fortran et C/C++ d'Intel et de GNU sont disponibles sur la machine.

Compilateurs par défaut

Les compilateurs GNU (gcc pour C/C++ et gfortran pour Fortran) sont accessibles par défaut (p.ex. /usr/bin/gcc*).

Compilateurs disponibles

- Des compilateurs GNU (gcc pour C, g++ pour C++ et gfortran pour Fortran) sont accessibles par défaut (/usr/bin) dans leur version "système". D'autres versions sont disponibles en chargeant le module correspondant.
- Les compilateurs intel (icc/icpc pour C/C++ et ifort pour Fortran) le seront après avoir chargé l'un des modules "Intel Compiler", par exemple :

module load intel/Compiler/13.1.3

Exemples de compilation

Les exemples de compilation seront donnés avec les compilateurs Intel (ifort pour Fortran et icc/icpc pour C/C++).

  • Exemple de compilation de codes séquentiels (1 seul cœur)
    • Compilation C/C++ :

      icc -o a.out code.c
    • Compilation Fortran :
      ifort -o a.out code.f

  • Exemple de compilation de codes parallèles ( MPI )

En parallèle, on utilise les compilateurs intel associés à la librairie MPI de SGI (MPT) par l’ajout de : "-lmpi"

D'autres distributions MPI sont disponibles sur la machine (après avoir chargé les modules correspondants), mais actuellement pas recommandées:
- IntelMPI en utilisant les wrappers mpicc or mpiifort
- OpenMPI en utilisant les wrappers mpicc, mpif90, ...

    • Compilation C/C++
avec MPT:        icc -lmpi -o a.out code.c

avec IntelMPI:   mpiicc -o a.out code.c

    • Compilation Fortran
avec MPT:        ifort -lmpi -o a.out code.f

avec IntelMPI: 	mpiifort -o a.out code.f

    • Exemple de compilation de codes multiprocesseurs (mémoire partagée - OpenMP)

Si on utilise OpenMP pour la parallélisation, l’option -openmp doit être passée au compilateur intel.

    • Compilation C/C++ :

      icc -openmp -o a.out code.c
    • Compilation Fortran :
      ifort –openmp -o a.out code.f

Principales options de compilation

Ces options sont communes aux 3 modes

-g debug (p.ex avec gdb)
-On n=1, 2, 3 optimisation générique, O3 à privilégier
-xSSE4.2 instructions spécifiques aux processeurs de la machine
-traceback avec -g , affiche la ligne en cas d’arrêt de l’exécution
-fpe0 stoppe l’exécution en cas de NaN ou division par zéro

Pour d’autres options, man ifort / icc

Ce lien vous permet de savoir la ligne exacte à utiliser pour linker avec les diverses composantes de MKL (BLAS, LAPACK,...), selon vos besoins :

MKL link line advisor

Exécution

La soumission des travaux se fait IMPERATIVEMENT en batch (via PBS), le travail en direct étant limité aux travaux de développement, compilation, pré/post-traitement léger, ...

Les librairies permettant le développement d’applications parallèles sont d’une part OPENMP, d’autre part MPI OPENMPI, SGI MPT, INTEL MPI. Les outils de debug disponibles sont intel debugger ainsi que ddt. Le nombre de licences est de 4 . Concernant les outils de trace, celui disponible sur Kepler est Intel Trace Analyser (itac version 8.0.0.011). Les librairies mathématiques installées sont Intel Math Kernel (version 10.2.5.035 et 038) ainsi que NAG (BLAS, LAPACK,…, librairie fortran mathématique, librairie C mathématique).

Exemples

  • Exemple d’exécution de codes séquentiels (1 seul cœur):

    ./a.out
  • Exemple d’exécution de codes parallèles ( MPI ) :
    mpirun ./a.out
  • Exemple d’exécution de codes multiprocesseurs (mémoire partagée) :
    export OMP_NUM_THREADS = number_of_threads
    ./a.out

    L’exécution d’un binaire utilisant OpenMP se déroule donc de la même façon qu’un exécutable série excepté le fait qu’il faut spécifier le nombre de threads utilisés (nombre maximum de threads = 64) :

Soumission de travaux en batch ("jobs")

Tous les jobs doivent être soumis "en batch" via PBS. Aucun calcul direct n'est autorisé.
Les jobs ne respectant pas cette règle sont tués sans aucun avertissement.

Files d’attente (180 coeurs dédiés)

Imposer certaines limites dans l'utilisation de la machine est une nécessité afin d'assurer un partage équitable des ressources entre les utilisateurs actifs. Les tableaux ci-dessous regroupent les principales règles de configuration du gestionnaires des queues (PBS Pro).

En plus de ces limites par queue, une limite globale a été également rajoutée récemment :

nombre max de coeurs alloués par utilisateur = 64 (toutes queues confondues)

  • Pour les jobs séquentiels (un seul coeur), utiliser les files d’attente seqXX
  • Pour les jobs parallèles (OpenMP, MPI), utiliser les files d’attente parXX

Configuration au 01.07.2013 (utiliser qstat -fQ pour voir la situation à jour)

Queues SEQUENTIELLES

Queue Durée max. Memoire par job (par défaut - max) No. max. jobs / queue No. max. jobs / user
seq12 12h 32 - 32 Go 4 2
seq24 24h 32 - 64 Go 3 2
seq48 48h 32 - 256 Go 4 2

Queues PARALLELES

Queue Durée max. No. cores par job Memoire par job (par défaut - max) No. max. jobs / queue No. max. jobs / user
par4 4h 2 à 6 32 - 32 Go 4 2
par12 12h 2 à 24 32 - 128 Go 4 2
par48 48h 2 à 48 32 - 320 Go 2 1

Queues de TEST (jobs parallèles ou séquentiels)

Queue Durée max. No. cores par job Memoire par job (par défaut - max) No. max. jobs / queue No. max. jobs / user
test 1 h 1 à 24 32 - 128 Go 20 2

Queues SPECIALES sur DEMANDE (séquentiel ou parallèle)

Ces queues sont accessibles sur demande écrite. Un argumentaire solide justifiant les besoins spécifiques est à fournir. Le bureau du PMCS2I décidera si la demande est acceptée ou pas.

Queue Durée max. No. cores par job Memoire par job (par défaut - max) No. max. jobs / queue No. max. jobs / user
partest - 1 à 128 5 - 512 Go - 1

Remarques importantes :

  • Etant donné l'architecture de la machine, dans la configuration actuelle, il n'est pas possible de partager un socket (CPU à 6 cores + mémoire RAM 32 Go) entre plusieurs jobs (que ce soit séquentiels ou pas). Dans la mesure du possible, les utilisateurs sont ainsi encouragés à utiliser au mieux les ressources demandés et en particulier :
    • pour les jobs parallèles: utiliser un nombre de coeurs multiple de 6 (où très légèrement inférieur)
    • pour les jobs séquentiels :
      • utiliser au moins les options de parallélisation automatique des compilateurs. D'autre part, avec un effort de développement relativement petit, on pourrait utiliser des librairies optimisées pour accélérer les zones du code les plus gourmandes en temps CPU
      • envoyer plusieurs "instances" au sein du même job (plusieurs programmes séquentiels séparés par "&") leur nombre (normalement, au plus 6) pouvant être mieux estimés lors des petits tests de "montée en charge")

  • Pour une meilleure flexibilité (remplissage, besoins ponctuels), ces limites sont susceptibles de modifications temporaires

  • Le partage équitable (fairesharing) est activé sur cput (=CPU time = durée x no. coeurs): plus on a utilisé dernièrement de cput et plus notre job demande de cput, moins il sera prioritaire.

  • Pour tout question/demande spécifique, merci de contacter l'équipe support

Commandes usuelles PBS (travail non interactif)

  • Soumission d’un travail :

    qsub job.pbs

    Cette commande retourne le "jobid" (identificateur du job), p.ex. : 33456.kepler

  • Etat de tous les jobs de l'utilisateur et état détaillé d'un job :
    qstat | grep $USER
  • Etat détaillé d'un job :
    qstat –f 33456
  • Etat détaillé d'un job déjà fini :
    qstat –fx 33456
  • Arrêt du job :
    qdel jobid
  • Etat des files d’attente :
    qstat ou qstat –a
  • Etat de l'utilisation de la machine :
    pbsnodes -a

    Les lignes suivantes sont à suivre :

    ...
         resources_available.mem = 1006387200kb
         resources_available.ncpus = 180
         ...
         resources_assigned.mem = 378044416kb
         resources_assigned.ncpus = 140
         ...

    ce qui veut dire qu'il y a 140 coeurs (sur 180) assignées pas PBS, ainsi que 378 Go (sur 1000 Go = 1To) de mémoire attribuée par PBS aux jobs en cours d'exécution.

Remarque Le système actuel sur Kepler fait une allocation des processeurs et de la mémoire de type "exclusif". Autrement dit si un coeur est alloué pour un job séquentiel, alors la totalité du processeur respectif (les 6 coeurs + la mémoire physiquement associée, i.e. 32 Go) est mobilisé (i.e. affecté en exclusivité) pour le job respectif.
De ce fait la valeur affichée par pbsnodes -a pour le nombre de coeurs assignés (resources_assigned.ncpus=140 dans l'exemple ci-dessus) est inférieure au nombre total de coeurs "bloqués" pour les jobs en cours. Cette différence apparaît lorsque des jobs séquentiels ou des jobs parallèles utilisant un nombre de coeurs non multiple de 6 sont en état "Running".

  • Etat de l'utilisation des processeurs :

    qmgr -c "p n @active" | grep state

    Exemple :

    kepler:~ # qmgr -c "p n @active" | grep state
    set node kepler state = free
    set node kepler[26] state = job-exclusive
    set node kepler[17] state = job-exclusive
    set node kepler[4] state = job-exclusive
    set node kepler[27] state = job-exclusive
    set node kepler[18] state = job-exclusive
    set node kepler[5] state = job-exclusive
    set node kepler[28] state = job-exclusive
    set node kepler[19] state = job-exclusive
    set node kepler[6] state = job-exclusive
    set node kepler[29] state = job-exclusive
    set node kepler[7] state = free
    set node kepler[8] state = job-exclusive
    set node kepler[9] state = job-exclusive
    set node kepler[10] state = job-exclusive
    set node kepler[20] state = job-exclusive
    set node kepler[11] state = job-exclusive
    set node kepler[30] state = job-exclusive
    set node kepler[21] state = job-exclusive
    set node kepler[12] state = job-exclusive
    set node kepler[31] state = job-exclusive
    set node kepler[22] state = job-exclusive
    set node kepler[13] state = job-exclusive
    set node kepler[0] state = Stale
    set node kepler[23] state = job-exclusive
    set node kepler[14] state = job-exclusive
    set node kepler[1] state = Stale
    set node kepler[24] state = job-exclusive
    set node kepler[15] state = job-exclusive
    set node kepler[2] state = job-exclusive
    set node kepler[25] state = job-exclusive
    set node kepler[16] state = free
    set node kepler[3] state = job-exclusive

    Dans cet example, seuls 2 processors (à 6 coeurs) sont disponibles : kepler7 et kepler16 (dans la numérotation de 0 à 31)

Travail en interactif via PBS

Il est possible de travailler en interactif (par exemple travail avec Matlab, débogage programme parallèle, etc. ) en soumettant un job de type interactif à PBS :

qsub -I -q queue_name

Le job sera positionné dans la file d'attente comme tout autre job.
Il est possible d'ouvrir des interfaces graphiques (p.ex. celle de Matlab) en rajoutant l'option -v DISPLAY.
Il est aussi possible de raffiner la demande de ressources pour le job interactif :

qsub -I -q seq12 -l select=1:ncpus=1:mem=31gb

Toutes les options qui peuvent être prescrites dans les scripts de soumission (voir section suivante) peuvent être aussi prescrites en ligne de commande (pour un job interactif ou pas).

Exemples de scripts

Attention : Utiliser la copier-coller des scripts ci-après pourrait poser de problèmes d'encodage des caractères

Exemple de script pour l'exécution de codes séquentiels

#!/bin/bash
#PBS -j oe
#PBS -o txt.out
#PBS -l walltime=30:00:00
#PBS -l select=1:ncpus=1:mem=2gb
#PBS -q seq48
#PBS -N <nom_job>
#PBS –m abe –M adresse@....

. $MODULESHOME/init/bash
module purge
module load intel/Compiler/11.1.073 intel/mkl/10.2.6.038

cd $PBS_O_WORKDIR
pwd
time /chemin/nom_programme  > out_prog.txt

Explications

# !/bin/bash : transmet à PBS l’environnement utilisé
#PBS –j oe : [optionnel] redirige les sorties et les erreurs dans le même fichier nommé ligne suivante « txt.out » (optionnelle elle aussi)
#PBS -l walltime=30:00:00 : [obligatoire] définit le temps max. alloué demandé pour ce calcul (hh:mn:sec)
#PBS -l select=1:ncpus=1:mem=2gb [obligatoire] signifie qu'on demande l'allocation d'1 nœud (obligatoire sur Kepler), d'1 cœur et  de 2Go de RAMpour ce job 
#PBS -q seq48 : utilisation de la file d’attente « seq48 » ([obligatoire], choisir la queue adéquate)
#PBS -N <nom_job> : définit le nom du job [obligatoire]
#PBS –m abe –M adresse@.... : [optionnel, mais conseillé] permet de recevoir un mail en début et fin d’exécution 
cd $PBS_O_WORKDIR [optionnel, mais important], change le répertoire vers le répertoire d'où on a soumis le job 
time /chemin/nom_programme : lancement de votre programme nom_programme avec mesure du temps CPU 
> out_prog.txt : pour rediriger l'output dans ce fichier (sinon la sortie sera faite dans /scratch/pbs/spool/spool/job_ID.kepler.OU)

Remarques

  • Une fois que le job se lance correctement (c.à.d. qu'il n'y ait pas eu d'erreur d'écriture du script, de chemins, etc.), le job aura le statut "Running" (R si on regarde avec qstat). Il s'arrêtera une fois que toutes les lignes du script aient été exécutées (y compris la ligne principale, à savoir l'exécution du code, p.ex. nom_programme dans l'exemple ci-dessus) ou bien si l'exécution de ces lignes (notamment celle de l'exécution du code) aurait besoin de plus de ressources que celles demandées dans le script (mémoire CPU, walltime). Dans le second cas, un message d'erreur devrait être retourné dans le fichier d'erreurs (txt.out, dans l'exemple ci-dessus).

  • pour s'assurer que le programme s'arrête correctement (et donc pour éviter le second cas décrit ci-dessus), il convient à demander une durée maximale (walltime) et une quantité de mémoire légèrement supérieures aux besoins du programme.

  • une demande exagérée de ressources (walltime, mémoire RAM, nombre de coeurs de calcul) par rapport au besoins réels du programme n'est pas désirable, puisque cela penaliserait tout le monde :
    • l'utilisateur, lors des futures soumissions de jobs, car les ressources demandées auparavant sont un critère pour le calcul des priorités des jobs dans les queues
    • les autres utilisateurs, car les ressources sont en exclusivité allouées, donc elles ne pourront pas être utilisées par d'autres jobs, qui resteront plus longtemps dans les queues
    • les administrateurs système qui n'apprécient pas que les ressources soit bloquées mais pas ou peu utilisées...
    • les sponsors, pour presque les mêmes raisons

  • il convient donc, avant de lancer de programmes de longue durée, d'effectuer une phase de test (en lançant de jobs de courte durée - par exemple dans la queue "test" ou en interactif, sur un nombre réduit d'itérations ou de pas de temps), afin de régler au mieux les ressources demandées dans le script (en extrapolant les résultats des tests aux cas réel de la simulation). La commande linux "top" peut être utilisée pour suivre la mémoire des processus tournant sur la machine (top -u $USER pour suivre que ses propres programmes). Si besoin, d'autres outils plus poussés sont disponibles sur Kepler pour regarder de plus près l'empreinte mémoire et le profilage des programmes.

  • si on veut simplifier, concernant la mémoire RAM, en pratique on a deux possibilités :
    • soit ne pas renseigner le paramètre mem=; dans ce cas, PBS allouera la mémoire par défaut (32 Go) de la queue demandée (voir les tableaux des queues)
    • soit renseigner ce paramètre dans le cas où les besoins du programme dépassent 32Go RAM

Exemple de script pour l'exécution de codes parallèles ( MPI )

#!/bin/bash
#PBS -o txt.out
#PBS -j oe
#PBS -l walltime=24:00:00
#PBS -l select=1:ncpus=32:mpiprocs=32:mem=10gb
#PBS -N <nom_job>
#PBS -q par48
#PBS –m abe –M adresse@....

. $MODULESHOME/init/bash
module purge
module load intel/Compiler/11.1.073 mpt/2.01 intel/mkl/10.2.6.038

cd $PBS_O_WORKDIR
pwd
mpirun /chemin/nom_programme_parallel > out_prog_parallel.txt

Explications

 
Le paramètre mpiprocs=32 indique le nombre de processes MPI 

Remarques

La plupart des distributions MPI installées sur la machine (notamment MPT) ont été construites avec support PBS, ce qui signifie qu'il n'y a pas besoin de renseigner le fichier de hostfile (option -hostfile filename), ni le nombre de processes MPI (option -np proc_number). Si toutefois ce fichier est nécessaire, il se trouve dans la variable PBS_NODEFILE.

Exemple de script pour exécution de codes multiprocesseurs (mémoire partagée OpenMP)

#!/bin/bash
#PBS -o txt.out
#PBS -j oe
#PBS -l walltime=24:00:00
#PBS -l select=1:ncpus=32:mem=10gb
#PBS -N <nom_job>
#PBS -q par48
#PBS –m ae –M adresse@....

. $MODULESHOME/init/bash
module purge
module load intel/Compiler/11.1.073  intel/mkl/10.2.6.038

export OMP_NUM_THREADS=32
cd $PBS_O_WORKDIR
pwd
/chemin/nom_programme_omp  > out_omp.txt

Quelle quantité de mémoire demander (paramètre mem=)

Pour les jobs parallèles, une fois que le nombre de coeurs à été déterminé (et renseigné via le paramètre ncpus=xx), la quantité de mémoire demandée doit bien sûr se faire en fonction des besoins du programme (s'il est ou pas "gourmand" en mémoire), mais en pratique on a deux possibilités :

  • soit ne pas renseigner ce paramètre; dans ce cas, PBS allouera la mémoire par défaut de la queue demandée (voir les tableaux des queues)
  • soit renseigner ce paramètre en utilisant :
    • une valeur "basse" (pour les programmes utilisant peu de mémoire) p.ex. ncpus * 1gb
    • ou une valeur "haute" (pour les programmes utilisant beaucoup de mémoire) p.ex. ncpus * 2gb, ou ncpus * 3gb, … jusqu'à ncpus * 5gb (ces valeurs sont à calculer et à renseigner manuellement, p.ex. pour 12 coeurs on peut mettre jusqu'à mem=60gb)

De cette façon, le système utilisera seulement la mémoire physiquement associée aux processeurs demandés (rappel : sur Kepler, chaque possesseur possède 6 coeurs et accède directement à maximum 32 GB de mémoire qui est physiquement associée, l'ensemble des ressources d'un processeur (coeurs et mémoire) ayant un usage "job exclusif"). En évitant d'allouer de mémoire associée à d'autres processeurs, l'accès mémoire sera amelioré et les processeurs de la machine seront mieux utilisées (pas des processeurs alloués sans être utilisés).

Jobs enchaînés

Dans certains cas, il est intéressant d'utiliser des jobs en cascade en mettant en oeuvre des dépendances. Exemple typique : traiter des problèmes évolutifs dont le CPU time dépasse les limites de "walltime" maximales des queues. En divisant convenablement l'intervalle de simulation en sous intervalles, les sous-problèmes pourront être lancés individuellement.

Exemple 1 : si on veut que le job2.pbs soit lancé seulement une fois que job1.pbs ait finit :

kepler:~> qsub job1.pbs
33474.kepler
kepler:~> qsub -W depend=afterok:33474 job2.pbs
33475.kepler

Exemple 2 : L'exécution du script "sequence" ci-dessous permet de soumettre automatiquement et au même moment deux jobs en dépendance :

kepler:~>  cat ./sequence 
#!/bin/bash
#
job1ID=`qsub script.test.seq12`
echo $job1ID 
job2ID=`qsub -W depend=afterok:$job1ID script.test.seq24`
echo $job2ID 
# etc.

kepler:~> ./sequence 
33474.kepler
33475.kepler

On peut remarquer l'état des jobs : le premier un en R(unning) et l'autre en H(old) :

kepler:~> qstat 
Job id            Name             User              Time Use S Queue
----------------  ---------------- ----------------  -------- - -----
33474.kepler      test.seq12       mon_login         00:00:00 R seq12           
33475.kepler      test.seq24       mon_login                0 H seq24

Utilisation de l'espace /scratch

Pour utiliser l'espace "de scratch" :
- créer vous mêmes un répertoire (selon votre login) dans cet espace : /scratch/USERS/login
- rajouter dans le script de soumission des commandes de copie des fichiers input depuis le home directory vers le scratch (avant la ligne d'exécution du programme) et de copie des fichiers output dans le sens inverse (après la ligne d'exécution du programme).

Programmes séquentiels multiples (multi-instances)

Lorsqu'on a besoin de lancer plusieurs programmes purement séquentiels qui n'utilise pas énormément de mémoire RAM (p.ex en dessous de quelques Go) , une possibilité assez simple à mettre en place serait de lancer plusieurs de tels programmes au sein du même job "séquentiel" (p.ex. de la queue seq24) :

dans le fichier de batch qui est soumis par qsub, apres les directives #PBS, utiliser :

cd /mon_home/.../Dir1
/mon_home/... prog1 < input_file1 > output_file1 &
cd /mon_home/.../Dir2
/mon_home/... prog2 < input_file2 > output_file2 &
...
cd /mon_home/.../DirN
/mon_home/... progN < input_fileN > output_fileN &
wait

(N peut aller jusqu'à 6, l'idée étant que les processeurs de Kepler ont 6 coeurs et que c'est une allocation exclusive, ç.à.d si un seul coeur d'un processeur est alloué, les 5 autres restants ne peuvent pas être utilisés par un autre job; donc ça serait mieux si on peux les faire travailler également, au lieu de soumettre un autre job auquel on lui aallouera un autre processeur à 6 coeurs, etc.)

A demander également un peu plus de mémoire (cette mémoire sera partagée entre les N programmes), c.à.d. dans la directive PBS :

#PBS -l select=1:ncpus=1:mem=32gb

(32 Go c'est la mémoire "exclusive" d'un processeur à 6 coeurs; on peut allouer plus si besoin, mais dans ce cas il vaut probablement mieux lancer un autre job avec un autre nombre N des programmes dedans)

Il faudra s'attendre à une durée un peu plus grande lorsqu'on lance N programmes au lieu d'un seul programme, mais globalement on gagne en rapidité. A titre d'exemple, pour des tests sur un certain codes séquentiel, on a obtenu une durée d'environ 4% plus grande pour N=2 programmes au lieu d'un seul, et de 20-25% pour N=6 au lieu d'un seul, mais pendant cette durée on obtient 2 ou 6 simulations finies au lieu d'une seule.

Attention : Cette technique s'avère ne pas fonctionner pour certaines logiciels, comme Matlab (ce logiciel semble ne pas admettre de process Matlab en background). Pour ces logiciels, regardez plutôt du coté de leur auto-parallélisation.

Utilisation de logiciels spécifiques

Matlab

Pour utiliser Matlab en mode batch, utilisez une telle ligne de commande dans le script de soumission PBS :

matlab -nojvm -nodesktop -nosplash < prog.m

ou

matlab -nojvm -nodesktop -nosplash -r 'prog ; exit'

RESERVATION DE RESSOURCES AVEC PBS

Cette fonctionnalité ne doit être utilisée que dans des fins de développement, deboggage, etc. , mais pas pour la production effective.

Elle permet de reserver par avance un nombre de ressources sur la machine (coeurs et mémoire) pour un créneau bien défini.

Types de réservation

Deux types de réservation sont acceptées par PBS :

  • advance reservation
  • standing reservation (les réservations recurrentes)

Créer une réservation

On présente ici seulement les "advance reservations". Pour les réservations récurrents ainsi que pour tout complément d'information veuillez vous rapporter au chapitre 8 du guide des utilisateurs PBS.

Principe

Une fois fois la réservation créée (si valide), une queue spécifique est créée. Les jobs seront soumis à cette queue.

Commande

pbs_rsub

Options

  • D : la durée
  • E : end time
  • R : start time
  • -l ... : la spécification des ressources (nb de coeurs, la mémoire : comme à la soumission de jobs, avec qsub)
  • -M : la specification de l'adresse e-mail comme à la soumission de jobs (avec qsub)

Exemples

  • Réserver toute la machine (évidemment cela n'est pas conseillée...) à partir de 11h30 pour une durée de 30 minutes
pbs_rsub -R 1130 -D 00:30:00

  • Réserver 2 coeurs sur un noeud (rappel : pour PBS, Kepler a un seul noeud) de 20h00 à 22h00
pbs_rsub -R 2000.00 -E 2200.00 -l select=1:ncpus=2

(ici les .00 sont les secondes pour si on veut être extrêmement précis...)

  • Réserver à une date autre que aujourd'hui : supposons qu'aujourd'hui est lundi 23 et on veut réserver pour demain 24 à 14h30 pour une durée de 2h :
pbs_rsub -R 241430 -D 02:00:00 -l select=1:ncpus=16:mem=10gb -M mon_adresse@lyon.fr

  • Rajouter un group ou une liste d'utilisateurs : -G groupname ou -U users_list

Etat d'une réservation

Commande

pbs_rstat

Options

  • B : Brief
  • S : Short
  • F : Full
  • par défaut : S

Exemples

  • voir brièvement nos réservations :
pbs_rstat -B

  • voir nos réservations en format "short" output :
pbs_rstat -S

Etat de la queue de réservation

qstat - fQ nom_queue

comme pour les queues standard

Supprimer une réservation

Commande

pbs_rdel

Exemple

pbs_rdel reservationID

(reservationID est retourné lors la création de la réservation

va supprimer également la queue correspondant et les jobs de la queue (!)

Un courriel sera envoyé (soit sur la boite mail de l'utilisateur Kepler soit à l'adresse mail indiquée lors de la demande de réservation) :

PBS Reservation Id: R107690.kepler
Reservation Name:   NULL
Reservation removed
Requesting party: username@kepler

Utiliser la réservation (soumettre des jobs)

Soumettre un job dans la queue de réservation

qsub -q reservation_queue script

(comme pour toute autre queue standard)

Déplacer un job normal dans la queue de réservation

qmove reservation_queue jobID

(comme pour toute autre queue standard)

Utilisation de la réservation par d'autres utilisateurs

Par défaut, seul l'utilisateur ayant fait la demande de réservation peut y soumettre de jobs à la queue de réservation.
Cependant, d'autres utilisateurs peuvent être autorisés à l'utiliser, mais pour cela ils doivent être déclarés lors de la demande de réservation.
Exemple :

pbs_rsub -R 1400 -D 02:00:00 -l select=1:ncpus=16:mem=10gb -U user2,user3

où user2, user3 sont les noms de login de deux autres utilisateurs.

Exemple complet

  • Demande de création de la réservation.

Dans cet exemple, on demande une réservation de 16 coeurs et 10 Go de mémoire RAM pour aujourd'hui à partir de 14h00 pour une durée de 1h :

username@kepler:~> pbs_rsub -R 1400 -D 01:00:00 -l select=1:ncpus=16:mem=10gb
R53355.kepler UNCONFIRMED

  • Si demande valide, réception message e-mail de la part de root vers adresse mail eventuellement indiquée dans la demande précédente (avec option -M adresse@mail) ou vers boite personnelle de l'utilisateur Kepler, dans ce dernier cas, le message sur le terminal apparaît : You have mail in /var/spool/mail/username) :
PBS Reservation Id: R53355.kepler
Reservation Name:   NULL
Reservation transitioned from state UNCONFIRMED to CONFIRMED
 -> WARNING: reservation R53355.kepler confirmed, but if reservation starts now, its jobs are not guaranteed to run as  pbs_license_min=1 < 192 (# of cpus in the complex)

  • Etat de la reservation (déjà commencée) :
username@kepler:~> pbs_rstat
Name       Queue    User     State             Start / Duration / End              
---------------------------------------------------------------------
R53355.kep R53355   username RN          Today 14:00 / 3600 / Today 15:00      
username@kepler:~> pbs_rstat -B
Name: R53355.kepler
username@kepler:~> pbs_rstat -F

Name: R53355.kepler
Reserve_Name = NULL
Reserve_Owner = username@kepler
reserve_state = RESV_RUNNING
reserve_substate = 5
reserve_start = Fri Jun 20 14:00:00 2014
reserve_end = Fri Jun 20 15:00:00 2014
reserve_duration = 3600
queue = R53355
Resource_List.ncpus = 16
Resource_List.walltime = 01:00:00
Resource_List.nodect = 1
Resource_List.select = 1:ncpus=16
Resource_List.place = free
resv_nodes = (kepler[26]:ncpus=6+kepler[31]:ncpus=6+kepler[24]:ncpus=4)
Authorized_Users = username@kepler
server = kepler
ctime = Fri Jun 20 13:58:16 2014
mtime = Fri Jun 20 13:58:16 2014
Variable_List = PBS_O_LOGNAME=username,PBS_O_HOST=kepler,PBS_O_MAIL=/var/mail/username

  • Etat de la machine (lorsque la réservation est déjà commencée) :

kepler:~ # qmgr -c "p n @active" | grep state
set node kepler state = free
set node kepler[26] state = resv-exclusive  <--
set node kepler[17] state = job-exclusive
set node kepler[4] state = job-exclusive
set node kepler[27] state = job-exclusive
set node kepler[18] state = job-exclusive
set node kepler[5] state = job-exclusive
set node kepler[28] state = job-exclusive
set node kepler[19] state = job-exclusive
set node kepler[6] state = job-exclusive
set node kepler[29] state = job-exclusive
set node kepler[7] state = job-exclusive
set node kepler[8] state = job-exclusive
set node kepler[9] state = job-exclusive
set node kepler[10] state = job-exclusive
set node kepler[20] state = job-exclusive
set node kepler[11] state = job-exclusive
set node kepler[30] state = job-exclusive
set node kepler[21] state = job-exclusive
set node kepler[12] state = job-exclusive
set node kepler[31] state = resv-exclusive  <--
set node kepler[22] state = job-exclusive
set node kepler[13] state = job-exclusive
set node kepler[0] state = Stale
set node kepler[23] state = job-exclusive
set node kepler[14] state = job-exclusive
set node kepler[1] state = Stale
set node kepler[24] state = resv-exclusive <--
set node kepler[15] state = job-exclusive
set node kepler[2] state = job-exclusive
set node kepler[25] state = job-exclusive
set node kepler[16] state = free
set node kepler[3] state = job-exclusive

  • Voir la queue spécifique

username@kepler:~> qstat -q

server: kepler

Queue            Memory CPU Time Walltime Node   Run   Que   Lm  State
---------------- ------ -------- -------- ---- ----- ----- ----  -----
weekend           320gb    --       --     --      0     0  100   D S
test               63gb    --    01:00:00  --      0     0   20   E R
seq12              32gb    --    12:00:00  --      0     0    6   E R
par4               32gb    --    04:00:00  --      2     0    6   E R
partest           500gb    --       --     --      0     0  100   D S
par48             313gb    --    48:00:00  --      2     0    4   E R
par12             125gb    --    12:00:00  --      4    13    7   E R
seq24              63gb    --    24:00:00  --      0     0    4   E R
seq48             250gb    --    48:00:00  --      0     0    5   E R
soleil            977gb    --       --     --      0     0  184   D S
R53355             --      --    01:00:00  --      0     0   --   E R          <--
                                               ----- -----
                                                   8    13

  • Soumettre un job à cette queue :

username@kepler:~/Submissions> qsub -q R53355 script.test.seq12
53361.kepler

username@kepler:~/Submissions> qstat -r

kepler: 
                                                            Req'd  Req'd   Elap
Job ID          Username Queue    Jobname    SessID NDS TSK Memory Time  S Time
--------------- -------- -------- ---------- ------ --- --- ------ ----- - -----
53256.kepler    user1   par12    SIMPLE      65863   1  12   63gb 11:57 R 06:14
53257.kepler    user2   par48    HPT1.5      82182   1  40   60gb 48:00 R 05:16
53259.kepler    user3   par12    canalPlan   84062   2  24   69gb 12:00 R 00:37
53265.kepler    user4   par48    2563004p8   88584   1  32  125gb 47:59 R 04:49
53294.kepler    user5   par12    SIMPLE       8593   1  12   63gb 11:57 R 02:25
53314.kepler    user6   par4     ch_turb     31035   1   2   10gb 03:59 R 02:08
53352.kepler    user7   par4     ch_turb     71770   1   2    1gb 03:59 R 01:35
53353.kepler    user8   par12    Circular    89717   1  16   20gb 11:59 R 00:18
53361.kepler    username R53355   test.seq12 104039   1   1    --  01:00 R 00:00                 <--   le job soumis est ici

Remarque : L'option en ligne -q R53355 prime sur la directive #PBS -q seq12 présente à l'intérieur du script script.test.seq12.

  • Soumettre plusieurs jobs à cette queue

username@kepler:~/Submissions> qsub -q R53355 script.test.seq12
53362.kepler
username@kepler:~/Submissions> qsub -q R53355 script.test.seq12
53363.kepler
username@kepler:~/Submissions> qsub -q R53355 script.test.seq12
53364.kepler
username@kepler:~/Submissions> qsub -q R53355 script.test.seq12
53365.kepler
username@kepler:~/Submissions> qsub -q R53355 script.test.seq12
53366.kepler

username@kepler:~/Submissions> qstat -a

kepler: 
                                                            Req'd  Req'd   Elap
Job ID          Username Queue    Jobname    SessID NDS TSK Memory Time  S Time
--------------- -------- -------- ---------- ------ --- --- ------ ----- - -----
...
53362.kepler   username R53355   test.seq12 106014   1   1    --  01:00 R 00:00
53363.kepler   username R53355   test.seq12 106061   1   1    --  01:00 R 00:00
53364.kepler   username R53355   test.seq12 106107   1   1    --  01:00 R 00:00
53365.kepler   username R53355   test.seq12    --    1   1    --  01:00 Q   -- 
53366.kepler   username R53355   test.seq12    --    1   1    --  01:00 Q   --

Remarque : C'est normal puisque seuls 3 CPU 6C sont réservés (mais les autres jobs vont passer en R eux aussi dès que ces premiers sont finis)

UTILISATION OPTIMISEE de KEPLER

"Distance" entre les processeurs

Cette commande permet de se rendre compte de la non uniformité de l'accès à la mémoire sur Kepler (architecture NUMA) :

dcalugar@kepler:~> numactl --hardware
available: 32 nodes (0-31)
node 0 cpus: 0 1 2 3 4 5
node 0 size: 32747 MB
node 0 free: 1458 MB
node 1 cpus: 6 7 8 9 10 11
node 1 size: 32768 MB
node 1 free: 27081 MB
node 2 cpus: 12 13 14 15 16 17
node 2 size: 32768 MB
node 2 free: 32256 MB
node 3 cpus: 18 19 20 21 22 23
node 3 size: 32752 MB
node 3 free: 32229 MB
node 4 cpus: 24 25 26 27 28 29
node 4 size: 32768 MB
node 4 free: 32120 MB
node 5 cpus: 30 31 32 33 34 35
node 5 size: 32752 MB
node 5 free: 31651 MB
node 6 cpus: 36 37 38 39 40 41
node 6 size: 32768 MB
node 6 free: 32214 MB
node 7 cpus: 42 43 44 45 46 47
node 7 size: 32752 MB
node 7 free: 32241 MB
node 8 cpus: 48 49 50 51 52 53
node 8 size: 32768 MB
node 8 free: 32257 MB
node 9 cpus: 54 55 56 57 58 59
node 9 size: 32752 MB
node 9 free: 32244 MB
node 10 cpus: 60 61 62 63 64 65
node 10 size: 32768 MB
node 10 free: 32259 MB
node 11 cpus: 66 67 68 69 70 71
node 11 size: 32752 MB
node 11 free: 32243 MB
node 12 cpus: 72 73 74 75 76 77
node 12 size: 32768 MB
node 12 free: 32258 MB
node 13 cpus: 78 79 80 81 82 83
node 13 size: 32752 MB
node 13 free: 32240 MB
node 14 cpus: 84 85 86 87 88 89
node 14 size: 32768 MB
node 14 free: 32255 MB
node 15 cpus: 90 91 92 93 94 95
node 15 size: 32752 MB
node 15 free: 31871 MB
node 16 cpus: 96 97 98 99 100 101
node 16 size: 32768 MB
node 16 free: 32259 MB
node 17 cpus: 102 103 104 105 106 107
node 17 size: 32752 MB
node 17 free: 32241 MB
node 18 cpus: 108 109 110 111 112 113
node 18 size: 32768 MB
node 18 free: 32260 MB
node 19 cpus: 114 115 116 117 118 119
node 19 size: 32752 MB
node 19 free: 31323 MB
node 20 cpus: 120 121 122 123 124 125
node 20 size: 32768 MB
node 20 free: 32260 MB
node 21 cpus: 126 127 128 129 130 131
node 21 size: 32752 MB
node 21 free: 32244 MB
node 22 cpus: 132 133 134 135 136 137
node 22 size: 32768 MB
node 22 free: 32261 MB
node 23 cpus: 138 139 140 141 142 143
node 23 size: 32752 MB
node 23 free: 32242 MB
node 24 cpus: 144 145 146 147 148 149
node 24 size: 32768 MB
node 24 free: 32260 MB
node 25 cpus: 150 151 152 153 154 155
node 25 size: 32752 MB
node 25 free: 32243 MB
node 26 cpus: 156 157 158 159 160 161
node 26 size: 32768 MB
node 26 free: 32259 MB
node 27 cpus: 162 163 164 165 166 167
node 27 size: 32752 MB
node 27 free: 32239 MB
node 28 cpus: 168 169 170 171 172 173
node 28 size: 32768 MB
node 28 free: 32252 MB
node 29 cpus: 174 175 176 177 178 179
node 29 size: 32752 MB
node 29 free: 32241 MB
node 30 cpus: 180 181 182 183 184 185
node 30 size: 32768 MB
node 30 free: 32261 MB
node 31 cpus: 186 187 188 189 190 191
node 31 size: 32752 MB
node 31 free: 32235 MB
node distances:
node   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31 
  0:  10  13  40  40  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48 
  1:  13  10  40  40  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48 
  2:  40  40  10  13  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40 
  3:  40  40  13  10  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40 
  4:  40  40  48  48  10  13  40  40  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55 
  5:  40  40  48  48  13  10  40  40  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55 
  6:  48  48  40  40  40  40  10  13  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48 
  7:  48  48  40  40  40  40  13  10  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48 
  8:  48  48  55  55  40  40  48  48  10  13  40  40  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62 
  9:  48  48  55  55  40  40  48  48  13  10  40  40  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62 
 10:  55  55  48  48  48  48  40  40  40  40  10  13  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55 
 11:  55  55  48  48  48  48  40  40  40  40  13  10  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55 
 12:  55  55  62  62  48  48  55  55  40  40  48  48  10  13  40  40  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69 
 13:  55  55  62  62  48  48  55  55  40  40  48  48  13  10  40  40  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69 
 14:  62  62  55  55  55  55  48  48  48  48  40  40  40  40  10  13  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62 
 15:  62  62  55  55  55  55  48  48  48  48  40  40  40  40  13  10  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62 
 16:  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48  10  13  40  40  40  40  48  48  48  48  55  55  55  55  62  62 
 17:  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48  13  10  40  40  40  40  48  48  48  48  55  55  55  55  62  62 
 18:  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40  40  40  10  13  48  48  40  40  55  55  48  48  62  62  55  55 
 19:  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40  40  40  13  10  48  48  40  40  55  55  48  48  62  62  55  55 
 20:  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48  10  13  40  40  40  40  48  48  48  48  55  55 
 21:  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48  13  10  40  40  40  40  48  48  48  48  55  55 
 22:  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40  40  40  10  13  48  48  40  40  55  55  48  48 
 23:  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40  40  40  13  10  48  48  40  40  55  55  48  48 
 24:  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48  10  13  40  40  40  40  48  48 
 25:  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48  13  10  40  40  40  40  48  48 
 26:  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40  40  40  10  13  48  48  40  40 
 27:  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40  40  40  13  10  48  48  40  40 
 28:  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48  10  13  40  40 
 29:  40  40  48  48  48  48  55  55  55  55  62  62  62  62  69  69  55  55  62  62  48  48  55  55  40  40  48  48  13  10  40  40 
 30:  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40  40  40  10  13 
 31:  48  48  40  40  55  55  48  48  62  62  55  55  69  69  62  62  62  62  55  55  55  55  48  48  48  48  40  40  40  40  13  10

Pour s'assurer d'une utilisation optimale des ressources (notamment d'un accès mémoire optimal), nous demandons aux utilisateurs les préconisations suivantes :

Programmes parallèles MPI, PVM

  • Utiliser MPT
  • Forcer la répartition des coeurs et l'allocation en local de la mémoire :

dplace -e -n nom_programme -c 0-31 numactl -l mpirun -np 32 nom_programme …

ici le programme "nom_programme" et a été lancée sur 32 coeurs

    • ça évite le load balancing des nouveaux noyaux Linux
    • la mémoire est allouée sur la même lame que le coeur de calcul alloué

Alternative : Pour les applications qui ne peuvent pas être re-compilées avec MPT, SGI propose l'alternative perfboost :

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=man&fname=/usr/share/catman/man1/perfboost.1.html

Principe d'utilisation :

perfboost {-pmpi | -impi | -ompi | -mpich }  cmd args

Au préalable, il faut charger les modules nécessaires :

module load mpt
module load perfboost

Autre alternative : Pour les applications dont chaque process parallèle est lancé séparément, on peut utiliser numactl pour positionner et la cpu et la mémoire :

numactl --physcpubind +cpu --membind +node nom_programme

qui exécutera le process nom_programme sur le coeur numéro cpu (relativement aux coeurs qui vous sont alloués) en allouant la mémoire sur le noeud numéro node (également relativement aux noeuds qui vous sont alloués). Bien sûr, on choisira le noeud qui contient le coeur choisi, sachant que le noeud 0 contient les coeurs 0 à 5, le noeud 1 les coeurs 6 à 11, etc....

Programmes PUREMENT séquentiels

Note : Par programme purement séquentiel, on entend un programme n'utilisant aucune bibliothèque parallèle (donc ni OpenMP, ni pthreads) ni de bibliothèque d'utilitaires parallélisée (MKL multi-threadée, MATLAB, …)

  • pour une allocation maximale de 32 GB :

numactl --physcpubind +0 --membind +0 nom_programme

  • pour une allocation supérieure à 32 GB :

numactl --physcpubind +0 --membind +0-number nom_programme

number est le numéro du dernier noeud utilisé (par noeud on entend ici processeur à 6 coeurs et 32 GB de mémoire)

  • pour un job comportant plusieurs instances (purement séquentielles)

numactl --physcpubind +0 --membind +0 nom_programme_1 &
numactl --physcpubind +1 --membind +0 nom_programme_2 &
…