Document Actions
Foire aux Questions
Questions / réponses fréquentes des utilisateurs
Configuration matérielle
- Quels espaces de travail sont à ma disposition ?
- Comment connaitre l'espace disque occupé dans /home, /work ?
- Quelle vision a-t-on du cluster d'IBM ?
Configuration logicielle
- Quels types d'application sont supportés par le cluster IBM ?
- Quelles librairies scientifiques sont installées sur le cluster IBM ?
Passage Illiac8 -> cluster IBM
- Peut-on ré-utiliser des fichiers binaires d'Illiac8 ?
- Comment porter un code d'Illiac8 vers le cluster IBM ?
- Correspondance d'options SGI / IBM
- Comment mesure-t-on le temps dans un programme ?
- Quelles sont les différences matérielles entre Illiac8 et le cluster IBM ?
- Quelles sont les différences logicielles entre Illiac8 et le cluster IBM ?
- Comment fonctionne la migration des données ?
Compilation
Portage
Déboguage
- Comment comprendre les messages d'erreur ?
- Comment comprendre les listings produits par le compilateur ?
- Comment déboguer un programme ?
- Que faire en cas de Segmentation Fault ?
Optimisation
- Comment optimiser un programme ?
- Comment localiser la consommation CPU d'un programme ?
- Comment analyser les communications d'une application parallèle MPI ?
- Comment localiser les cache misses dans les programmes ?
Exécution
- Exécution en interactif ou en batch ?
- Comment déterminer la consommation mémoire d'un code ?
- Pourquoi le système me dit qu'il n'y a pas assez de mémoire disponible ?
- Comment compiler et faire tourner un job MPI ?
- Comment compiler et faire tourner un job OpenMP ?
- Comment compiler et faire tourner un job PVM ?
Soumission batch Loadleveler
- Comment fonctionne la soumission des calculs ?
- Comment construire un script de soumission batch ?
- Comment soumettre, suivre ou détruire un job en batch ?
- Peut-on avoir accès aux fichiers d'un job durant son exécution en batch ?
- Que signifie le code d'erreur lors de la soumission du job ?
- A quoi servent les variables cri_initialdir et cri_finaldir ?
- Quelles sont les limites de ressources des jobs en batch ?
- Que signifie (alloc) dans la sortie de llq ?
- Que se passe-t'il si le wall_clock limit est atteint ?
- Que signifient les temps fournis dans le mail de fin par Loadleveler ?
En cas de problème
Configuration matérielle
Quels espaces de travail sont à ma disposition ?
Chaque utilisateur dispose d'un compte informatique sur le cluster IBM qui contient trois espaces disques permanents, munis de quotas disques.Il s'agit :
- d'un espace pour ses fichiers sources, $HOME_DIR dans le /home,
- d'un espace de travail, $HOME_WORK dans le /work,
- d'un espace dédié à la migration $HOME_SAVE dans le /save.
Ces trois espaces, sécurisés en RAID 5, sont physiquement localisés dans la baie externe FastT500 (voir la configuration du cluster).
L'espace $HOME_DIR sera prochainement doté d'un logiciel de sauvegarde.
La migration des fichiers se fait au travers du logiciel TSM, propriété d'IBM, sur le robot ADIC/Grau Scalar 1000. Voir la page consacrée au service de migration des données.
Enfin, lors de la soumission des calculs en batch, un espace de travail temporaire est alloué, au sein des disques locaux (400 Go disponibles par noeud), sur le noeud d'exécution du job, pour chaque soumission. Cet espace est libéré à la fin du job.
La procédure de soumission avec les contraintes qu'elle engendre est présentée dans la page consacrée au mode batch.
Voir aussi la page consacrée aux espaces de travail.
Comment connaitre l'espace disque occupé dans /home, /work ?
Tous les espaces disques attribués aux comptes utilisateurs sont soumis aux quotas.
La commande quota usuelle ne s'applique par pour les espaces /home et /work car ce sont
des systèmes de fichiers particuliers, de type GPFS (Global Parallel File System).
Il faut employer une commande particuliere
(en C Shell) alias qt '/usr/lpp/mmfs/bin/mmlsquota -v'
(en Korn Shell) alias qt='/usr/lpp/mmfs/bin/mmlsquota -v'
On obtient alors les informations suivantes (ou analogues) :
| Block Limits | ||||||
| Filesystem | type | KB | quota | limit | in_doubt | grace |
| home | USR | 118262 | 204800 | 225280 | 0 | none |
| indus | USR | 0 | 0 | 0 | 0 | none |
| work | USR | 4679528 | 7340032 | 7864320 | 0 | none |
Dans l'espace /home, 118262 ko sont occupés avec une limite de 204800 ko et un maximum de 225 280 ko. Si on dépasse la limite, il faut y rester moins de 7 jours consécutifs.
Dans l'espace /work, 4679528 ko sont occupés avec une limite de 7340032 ko et un maximum de 7864320 ko. L'espace /indus ne concerne que certains utilisateurs particuliers.
Quelle vision a-t-on du cluster d'IBM ?
L'utilisateur ne voit que la partie du cluster sur laquelle il se connecte, à savoir 4 processeurs et 4 Go de mémoire du noeud joe. Le reste de la configuration, inaccessible, est dédiée au batch.
Les jobs soumis en mode interactif prennent leurs ressources dans la partie de connection du noeud joe.
Les jobs soumis en mode batch prennent leurs ressources soit dans le reste du noeud joe soit dans le noeud jack selon les disponibilitées.
Les espaces permanents sont installés physiquement sur la baie FastT500 et sont vus par les deux noeuds. La procédure de soumission de calculs en batch inclut les phases de transfert automatique des fichiers entre l'espace permanent initial et le répertoire temporaire alloué dans les disques locaux du noeud d'exécution.
Il est important d'utiliser ces disques internes plutôt que les espaces permanents car les débits d'écriture / ecture sont nettement meilleurs et l'application en cours d'exécution n'est pas pénalisée.
Configuration logicielle
Quels types d'application sont supportés par le cluster IBM ?
Il n'y a, a priori, aucun exclusion particulière.
Les applications à base d'échanges de messages (MPI, PVM, ...) s'exécutent indifféremment sur un noeud ou à cheval sur plusieurs. Ce mode est choisi par défaut. Il est possible de l'inhiber, job par job, selon les besoins en communication de l'application. Voir la page consacrée à LoadLeveler pour plus de détails.
Les applications utilisant la mémoire partagée (OpenMP, p-threads, ...) ont comme contrainte de ne pas pouvoir sortir d'un noeud.
Quelles librairies scientifiques sont installées sur le cluster IBM ?
Plusieurs librairies scientifiques sont installées sur le cluster IBM :
- la librairie de fonctions mathématiques standards MASS ;
- la librairie scientifique ESSL et sa version parallèle P-ESSL ;
- la librairie domaine public BLAS est incluse dans ESSL ;
- la librairie domaine public LAPACK (en partie seulement dans ESSL).
Pour le détail des contenus et les modalités d'utilisation, vous pouvez consulter la page des bibliothèques scientifiques.
Passage Illiac8 -> cluster IBM
Peut-on ré-utiliser des fichiers binaires d'Illiac8 ?
Les fichiers de données binaires, comme les fichiers de reprise, les fichiers non formatées, ont la même représentation interne sur les machines SGI (en particulier les Origin2000 et Origin3000) et IBM (p690-Power4 et p575-Power5). Il n'y a donc aucun problème pour relire ces fichiers. Par contre, les fichiers objets, librairies, archives et exécutables doivent être recompilés.Comment porter un code d'Illiac8 vers le cluster IBM ?
Dans la mesure où le programme est écrit en respectant les rèles et la norme du langage, le portage devrait s'effectuer facilement avec peut-être quelques modifications mineures concernant la mesure du temps (s'il y a lieu).Pour un programme qui ne respecte pas complètement la norme, cela peut être plus long car le compilateur XLF n'accepte pas forcément des écarts tolérés par d'autres compilateurs, e.g. MIPSpro de SGI, et vice versa.
De manière générale, on peut suivre les principes énoncés ci-dessous :
- installer le code source dans le $HOME_DIR ;
- choisir un compilateur de la famille XLF ;
- compiler le programme avec des options de déboguage (voir Quelles options de compilation choisir ?);
- faire une exécution sur un cas test représentatif ;
- valider les résultats numériques ;
- monter le niveau d'optimisation (voir Comment optimiser un programme ?).
Correspondance d'options SGI / IBM
Le tableau suivant fournit quelques correspondances importantes lors du portage du code. Toutefois, il est vivement conseillé de parcourir les rubriques des pages sur les environnements XLF ou XLC.| Catégorie | Option SGI | Option IBM |
|---|---|---|
| Déboguage | -O0 -g -DEBUG:subscript_check=ON: trap_uninitialized=ON: div_check=3:verbose_runtime=ON |
-qnooptimize -qcheck -qdbg -qextchk -qflttrap=:ov:und:zero:inv:en -qfullpath -qinitauto=FF -qfloat=nans |
| Portage | -r8 | -qdpc=e -qautodbl=dbl4 |
| Optimisation (équivalence toute relative) | -r10000 -mips4 -O3 -OPT:IEEE_arithmetic=1:roundoff=0 | -qhot -O3 -qstrict -qarch=auto -qtune=auto |
Comment mesure-t-on le temps dans un programme ?
Les routines de mesure du temps sont décrites dans la partie page des conseils pratiques.
Quelles sont les différences matérielles entre Illiac8 et le cluster IBM ?
Illiac8 est un supercalculateur SGI Origin2000, 64 processeurs 32 Go de mémoire ccNUMA à image système unique. Cela signifie qu'une application peut utiliser toutes les ressources, qu'elle repose sur l'échange de messages ou la mémoire partagé.Le cluster IBM est composé de deux noeuds p690 Turbo (32 processeurs et 32 Go de mémoire chacun), indépendants, interconnectés par un switch haut débit Colony. Les applications à base d'échanges de messages (MPI, PVM, ...) s'exécutent indifféremment sur un noeud ou à cheval sur plusieurs, bien que ce dernier mode ne soit pas conseillé car peu performant. Les applications utilisant la mémoire partagée (OpenMP, p-threads, ...) ont comme contrainte de ne pas pouvoir sortir d'un noeud.
Les processeurs Power4 sur le cluster ont une fréquence d'horloge de 1.3 GHz, soit environ 6.5 fois celle des processeurs MIPS R10000 d'Illiac8 (195 MHz). Une différence importante est la capacité des processeurs Power4 de réaliser 4 opérations en virgule flottante par cycle d'horloge (2 couples addition-multiplication,
Quelles sont les différences logicielles entre Illiac8 et le cluster IBM ?
L'environnement de tout calculateur comprend des fonctionnalitées analogues : compilateurs, débogueur, outils l'analyse, bibliothèques scientifiques, soumission batch, etc ... ces outils étant plus ou moins équivalents. Le petit tableau suivant reprend ces comparaisons :| Logiciel | SGI | IBM | Liens vers les pages de la documentation |
|---|---|---|---|
| Compilateur | F77, F90, cc | xlf_r, xlf90_r, xlc, ... | XLF ou XLC |
| Débogueur | cvd, dbx | dbx, pdbx | Déboguage |
| Outils d'analyse | perfex, speedshop, workshop | prof, gprof | outils d'analyse |
| Bibliothèques scientifiques | BLAS, LAPACK, SCSL | BLAS, LAPACK, ESSL, P-ESSL | bibliothèques scientifiques |
| Soumission batch | NQE / NQS | Loadleveler | mode batch , Loadleveler. |
Comment fonctionne la migration des données ?
Le service de migration des données permet de placer des fichiers de résultats sur des bandes magnétiques dans le robot ADIC/Scalar 1000 comme c'était le cas auparavant sur Illiac8. Le fichier est soit présent sur disque uniquement, soit sur disque et sur bande magnétique, soit uniquement sur bande ce qui permet de libérer de la place disque tout en conservant un exemplaire du fichier. Il faut noter qu'il s'agit de migration et non pas de sauvegarde.Il repose sur le logiciel TSM, plus particulièrement son module HSM (Hierarchical Storage Manager). Vous pouvez consulter la page qui lui est consacrée.
Compilation
Quel compilateur choisir ?
Pour le Fortran, comme pour le C, il existe plusieurs commandes de compilation, toutes faisant référence au compilateur XLF ou XLC.
Pour les applications séquentielles il est conseillé d'utiliser la version threadsafe des compilateurs (extension _r) : xlf_r, xlf90_r ou xlf95_r selon la norme du Fortran souhaitée.
Cela est obligatoire pour les applications utilisant les threads (comme les programmes OpenMP).
Pour les applications MPI, il faut ajouter le préfixe mp : mpxlf_r, mpxlf90_r ou mpxlf95_r. Pour qu'un job soumis en batch puisse être checkpointé (arrêté et relancé aprè un reboot par exemple), il doit être compilé avec une version threadsafe des compilateurs.
voir les rubriques des compilateurs dans les pages sur leur environnement, XLF ou XLC qui reprennent ces informations.
Quelles options de compilation choisir ?
Les compilateurs XLF et b>XLC
possèdent de très nombreuses options qui sont regroupées par catégorie.
Ces différentes catégories sont présentées dans les pages consacrées à
leur environnement, XLF ou XLC.
Chaque rubrique propose un groupe d'options de base selon le but de la
compilation : déboguage, portage, optimisation, analyse des
optimisations au travers des listings de sortie de compilation, etc...
On peut aussi récupérer des fichiers de compilation Makefile qu'il suffit de compléter avec la liste des fichiers à compiler. Pour cela, vous pouvez consulter la rubrique Exemples de Makefile des pages consacrées aux environnements XLF ou XLC.
Portage
Existe-t'il un générateur de nombres pseudo-aléatoires portable en Fortran ?
Le Fortran 90 dispose de son propre générateur pseudo-aléatoire qui peut être appelé par des codes séquentiels, parallèles (MPI, OpenMP).
La page des Conseils pratiques propose des exemples pour son usage.
Déboguage
Comment comprendre les messages d'erreur ?
Les messages d'erreurs sont décrits dans la rubrique Messages d'erreur courants des pages consacrées aux environnements XLF ou XLC.
Comment comprendre les listings produits par le compilateur ?
Les listings produits par le compilateur sont décrits dans la rubrique Listings du compilateur des pages consacrées aux environnements XLF ou XLC.
Comment déboguer un programme ?
Déboguer un programme est une phase préliminaire à toute exploitation.
Pour cela (par exemple en Fortran) :
- on compile le code avec une séquence d'options adéquates (rubrique options de déboguage) ;
- on autorise la création de fichiers core avec la commande ulimit coredumpsize ;
- lors d'un éventuel plantage à l'exécution on utilise un débogueur symbolique comme dbx ou pdbx (une version parallèle de dbx) pour analyser les causes de l'arrêt.
On peut aussi consulter la pages desconseils pratiques.
Que faire en cas de Segmentation Fault ?
Le Segmentation Fault survient en cours d'exécution de programme lorsque l'espace mémoire que peuvent occuper les données est trop petit. Il peut y avoir plusieurs causes :
- limites interactives : le shell, environnement d'exécution du programme possède des limites par défaut qui peuvent être trop restrictives pour le programme : avec la commande unlimit on fait sauter cette barrière. On relance alors simplement le code.
- limites données à l'édition des liens : par défaut,
les programmes sont compilés pour un espace d'adressage stocké sur 32
bits, soit un volume mémoire total de 2 Go pour la pile (stack) et le tas (heap).
La pile a le droit d'occuper un volume maximal de un segment soit 256
Mo, elle contient les variables locales, les tableaux automatiques, ...
. Cette limite ne peut être dépassée en mode 32bits. Le tas a aussi une
limite par défaut de un segment soit 256 Mo, on peut la faire monter
jusqu'à 8 segments soit 2 Go avec l'option -bmaxdata avec -bmaxdata:0xY0000000 où Y indique le nombre de segments de 256 Mo que l'on veut réserver.
Pour un espace d'adressage sur 64bits, il n'y a plus de limites ni pour la stack, ni pour le heap, dans ce cas il ne faut pas utiliser l'option -bmaxdata. - sortie de l'adressage 32 bits : si l'ensemble des données adressées par un processus est supérieur à 2 Go de mémoire, on peut soit envisager de répartir différemment les données, soitd'augmenter le nombre de processus de l'application pour repasser sous la barre des 2 Go soit encore recompiler intégralement son programme en mode 64 bits, i.e les adresses mémoire sont stockées sur 64 bits et non plus sur 32. Dans ce cas il faut faire attention, surtout en C, ou les types entiers sont souvent utilisés comme pointeurs t contiennent alors es adresses mémoire !
- débordement de tableaux : il peut aussi s'agir d'un bogue du code lié à un débordement de tableaux. Dans ce cas il faut recompiler (rubrique options de déboguage) le code avec des options de déboguage adaptées, autoriser la création de fichiers core (ulimit coredumpsize) et ensuite analyser le fichier core généré lors du crash de l'application avec le débogueur symbolique dbx.
Optimisation
Comment optimiser un programme ?
L'optimisation se fait après le déboguage. Pour cela (par exemple en Fortran) :
- on compile le code avec une séquence d'options adéquates : rubriques optimisation (sans oublier les options de profilage comme -pg) et listing ;
- on étudie les listings générés lors de la compilation, voir la page sur l'environnement XLF, rubrique listings du compilateur ;
- on exécute le code en batch pour avoir des mesures plus fiables ;
- on analyse le compte-rendu d'exécution à l'aide d'outils de profilage comme gprof pour localiser les goulots d'étranglement.
- on valide la précision des résultats numériques pour chaque niveau d'optimisation testé.
Il ne faut pas trop se reposer sur les compilateurs XLF et b>XLC. En effet un travail d'optimisation à la main peut parfois être nécessaire pour obtenir de meilleures performances. Pour cela on peut consulter les pages des techniques d'optimisation et des conseils pratiques.
Comment localiser la consommation CPU d'un programme ?
L'analyse de la consommation CPU se fait à l'aide d'outils de profilage. Pour cela (par exemple en Fortran) :
- on compile le code avec des options d'optimisation et les options de profilage comme -pg ;
- on exécute le code en batch pour avoir des mesures plus fiables ;
- on analyse le compte-rendu d'exécution à l'aide d'outils de profilage comme gprof.
Comment analyser les communications d'une application parallèle MPI ?
Les communications représentent une phase importante dans une application parallèle MPI : par définition, elles sont un surcoût par rapport aux calculs effectués. Il est donc important de limiter au maximum leur impact. Pour tracer leur déroulement, on peut utiliser l'option trace de l'outil pct (Performance Collection Tool du PE Benchmarker d'IBM) qui permet de marquer les différents types de communications. Pour plus d'informations sur cet outil, voir sa page.On peut ensuite visualiser graphiquement (ou sous forme de statistiques) ces traces à l'aide de pvt (Profile Visualization Tool du PE Benchmarker d'IBM). Pour plus d'informations sur cet outil, voir sa page.
Comment localiser les cache misses d'un programme ?
Les cache misses (défauts de cache) surviennent lorsque le processeur a besoin de données qui ne figurent ni dans ses registres ni dans les différents niveaux de cache. Chercher ces données en mémoire est alors très pénalisant en terme de performances. Pour localiser les zones du programme qui génèrent beaucoup de cache misses, on peut les comptabiliser à l'aide des compteurs matériels. Pour cela, on utilise l'option profilage de l'outil pct. Pour plus d'informations sur cet outil, voir sa page.On peut ensuite visualiser graphiquement (ou sous forme de statistiques) ces traces à l'aide de jumpshot, outil graphique de l'Argonne National Laboratory. Pour plus d'informations sur cet outil, voir sa rubrique.
Exécution
Exécution en interactif ou en batch ?
Le cluster IBM est séparé en deux parties distinctes :
- une partie connection, compilation, interactif doté de ressources propres : 4 processeurs Power4 et 4 Go de mémoire, provenant du noeud 1, joe. Cela permet aux utilisateurs de travailler sur leurs fichiers source, faire des compilations, faire du déboguage, faire des courtes exécutions en interactif puisqu'une limite maximale de 900 secondes CPU est fixée (ce qui représente près de deux heures CPU sur un processeur d'Illiac8). Ces différentes activités se partagent ces ressources. Il faut noter que toute commande agit alors sur les fichiers stockés sur la baie externe FastT500, au travers de liens Fiber Channel dont le débit est inférieur d'un ordre de grandeur à ceux de disques locaux. Par conséquent il n'est pas recommandé de faire des tests d'écriture en interactif puisque les performances ne sont pas optimales et que ces liens servent aussi à ceux qui éditent des fichiers.
- une partie batch qui englobe le reste du noeud 1, soit 28 processeurs Power4 / 28 Go de mémoire d'une part et l'intégralité du noeud 2, jack, 32 processeurs Power4 / 32 Go de mémoire d'autre part. Il s'agit de deux "noeuds" indépendants. La possibilité de faire tourner un job à cheval sur les deux "noeuds" n'est pas activée en raison du manque de performances du switch d'interconnection Colony. L'accès à ces ressources se fait uniquement en mode batch au travers du logiciel de soumission loadleveler dont la procédure d'utilisation est présentée dans la page consacrée au mode batch.
Comment déterminer la consommation mémoire d'un code ?
Dès la compilation, le volume mémoire des données est imposé par le compilateur.
La mémoire est vue comme des segments de 256 Mo chacun. Par défaut, un seul est alloué pour les données globales (le heap). Si vous avez besoin de plus, cela peut se paramétrer avec l'option
Un corollaire direct est qu'un code qui passe en interactif vous donne
le nombre de segments mémoire nécessaires pour votre programme et donc
vous permet de renseigner la demande en mémoire pour une soumission en
batch. Il est impératif de donner à loadleveler une valeur au moins
égale au nombre de segments demandés lors de la compilation :
loadleveler se base aussi sur cela pour vérifier que le code ne prend
pas plus de mémoire que celle demandée.
Il faut noter qu'aussi bien lors de la compilation que pour loadleveler, il s'agit de valeur par processus : il n'y a pas de multiplication à faire !
Pourquoi le système me dit qu'il n'y a pas assez de mémoire disponible ?
Le message d'erreur suivant :
| exec(): 0509-036 Cannot load program ./ram.out because of the following errors: 0509-026 System error: There is not enough memory available now. |
En fait, il faut souvent chercher l'origine ailleurs que dans la surcharge de la machine !
La mémoire est vue comme des segments de 256 Mo chacun. Par défaut, un seul est alloué pour les données globales (le heap).
Si les données statiques (common, variables statiques,
variables initialisées, ...) remplissent plus que ce segment, le
programme ne peut démarrer. Il faut alors augmenter le nombre de
segments que le code peut être amener à occuper.
On employe alors l'option
La commande size permet de connaitre le volume
en mémoire de ces données et donc de déterminer le nombre de segments à
allouer. Par exemple le programme suivant :
| size -d -f ram.out ram.out: 3697(.text) + 335(.data) + 1316928012(.bss) + 949(.loader) + 12(.except) = 1316933005 |
Il faut donc ajouter l'option
Dans le cas où les données représentent plus de 2 Go de mémoire, il faut compiler en mode 64 bits avec l'option -q64 (les limites du compilateur).
Comment compiler et faire tourner un job MPI ?
L'exécution d'une application MPI repose sur l'environnement parallèle PE.
Prenons l'exemple du Fortran.
Un code MPI doit être compilé avec une commande de la famille mpxlf comme : mpxlf_r, mpxlf90_r ou mpxlf95_r. Voir la page de l'environnement de compilation.
On utilise des options analogues à celles d'un code séquentiel :
déboguage, optimisation, etc ... Il faut simplement préciser la
librairie MPI lors de l'édition des liens avec -lmpi.
Voir l'exemple simple de programme MPI : programme source, makefile, script de soumission à loadleveler.
Il y a plusieurs manières de lancer l'exécution d'un code MPI (ici sur 4 processus) :
Il convient de renseigner plusieurs variables d'environnement :
Ces initialisations sont faites par défaut.
Les commandes loadleveler pour l'exécution en mode batch sont :
Voir les pages consacrées à loadleveler et aux modes de soumission des jobs.
Comment compiler et faire tourner un job OpenMP ?
Un code OpenMP est un code séquentiel qui crée des threads. Il doit donc être compilé avec un compilateur threadsafe. Pour un programme écrit en fortran, il faut donc prendre une commande de la famille xlf_r comme : xlf_r, xlf90_r ou xlf95_r. Voir la page de l'environnement de compilation.
On utilise des options analogues à celles d'un code séquentiel :
déboguage, optimisation, etc ... Il faut simplement préciser l'option -qsmp=omp à la compilation. Le niveau d'optimisation doit au moins être -O3 pour que les optimisations liées à la parallélisation soient efficaces.
Voir l'exemple simple de programme OpenMP : programme source, makefile, script de soumission à loadleveler.
Il convient de renseigner plusieurs variables d'environnement :
Ces initialisations sont faites par défaut.
Les commandes loadleveler pour l'exécution en mode batch sont :
Attention !!
Sur les machines IBM, les threads OpenMP ne sont pas des "vrais"
processus, mais des processus légers. D'un point de vue ressources
consommées, elles sont donc incluses au sein de la thread maîtresse
soit le "vrai" processus de l'application.
Il ne faut pas oublier que la data_limit est la mémoire par processus (au sens IBM), il faut donc que vous déterminez la consommation mémoire de toutes les threads et que vous affectiez cette somme à la variable data_limit dans le script de soumission batch.
Voir les pages consacrées à loadleveler et aux modes de soumission des jobs.
Comment compiler et faire tourner un job PVM ?
La librairie PVM installée est la librairie domaine public puisque IBM ne supporte plus une version optimisée.
Il faut employer un compilateur threadsafe comme : xlf_r, xlf90_r ou xlf95_r. Voir la page de l'environnement de compilation.
On utilise des options analogues à celles d'un code séquentiel :
déboguage, optimisation, etc ... Il faut simplement préciser les
chemins vers les includes, les librairies PVM qui sont basés sur les
variables d'environnement PVM_ROOT et PVM_ARCH :
d'où :
On ajoute à la compilation -I$(PVMINCLUDE).
On ajoute à l'édition des liens -L$(PVMLIB) -lpvm3 -lfpvm3 -lgpvm3
Le lancement de l'exécution se fait après l'initialisation du daemon pvm avec echo quit | pvm.
Les commandes loadleveler pour l'exécution en mode batch sont :
Soumission batch Loadleveler
Comment fonctionne la soumission des calculs ?
On peut consulter les pages consacrées d'une part à Loadleveler et d'autre part aux modes de soumission des jobs.
Comment construire un script de soumission batch ?
On peut consulter les pages consacrées d'une part à Loadleveler et d'autre part aux modes de soumission des jobs.
On peut aussi récupérer des scripts type pour des soumissions de jobs séquentiels, MPI ou OpenMP, Gaussian ksh ou csh, Jaguar (ksh ou csh) et Gamess (ksh ou csh) .
Si vous ne trouvez pas de type de jobs qui corresponde à vos besoins, alors prenez contact avec nous en ouvrant un ticket d'assistance.
Comment soumettre, suivre ou détruire un job en batch ?
La commande llstatus -R permet de connaitre les ressources disponibles (d'après les ionformations en possession de Loadleveler) :
| llstatus -R | |
| Machine | Consumable Resource(Available, Total) |
| ------------------------------ | ------------------------------------------------- |
| ll-jack | ConsumableCpusCrihan(0,36) ConsumableMemCrihan(4400,36864) |
| ll-joe | ConsumableCpusCrihan(0,32) ConsumableMemCrihan(1556,32768) |
Les ConsumableCpusCrihan correspondent à des tickets processeurs sur chacun des noeuds : un ticket = un processeur Power4.
Les ConsumableCpusCrihan correspondent à des tickets mémoire sur chacun des noeuds : un ticket = un Mo de mémoire
La commande llsubmit permet de soumettre un job sur le cluster IBM.
La syntaxe est llsubmit job_script. On obtient alors une référence numéro_job de la forme ll-joe.xxxxx.0.
La commande llq permet de suivre son exécution.
On obtient un tableau récapitulatif de tous les jobs présents à ce
moment classés par autres décroissant de priorité. Pour chaque job, on
connait son numéro_job, le login de son propriéraire, le jour et l'heure de sa soumission, son statut (R = Running, I = Idle soit en attente) et le cas échéant le noeud d'exécution.
Pour les jobs MPI à cheval, il s'agit du noeud père.
| Id
Owner Submitted ST PRI Class
Running On ---------------- --------- ----------- -- --- ----------- ----------- ll-joe.19412.0 < login > 11/1 13:45 R 50 large ll-joe ll-joe.19475.0 < login > 11/4 16:12 R 50 medium ll-jack ll-joe.19448.0 < login > 11/4 09:37 R 50 large ll-joe ll-joe.19455.0 < login > 11/4 11:03 R 50 large ll-jack ll-joe.19510.0 < login > 11/5 15:22 R 50 large ll-jack ll-joe.19456.0 < login > 11/4 11:48 R 50 large ll-joe ll-joe.19536.0 < login > 11/8 10:43 R 50 large ll-jack ll-joe.19509.0 < login > 11/5 15:22 I 50 large ll-joe.19515.0 < login > 11/5 17:22 I 50 large ll-joe.19530.0 < login > 11/7 12:33 I 50 large ll-joe.19537.0 < login > 11/8 10:45 I 50 large 13 job step(s) in queue, 4 waiting, 0 pending, 9 running, 0 held, 0 preempted |
La commande llcancel permet de supprimer une requête soumise à Loadleveler.
La syntaxe est llcancel numéro_job.
Peut-on avoir accès aux fichiers d'un job durant son exécution en batch ?
Oui, tout à fait.
Voici la règle :
Faites un llq pour savoir sur quel noeud tourne votre job.
Exemple 1 :
Votre job est "Running On" ll-joe et son "jobid" est ll-joe.2222.0
Faites un "cd /local/run/ll-joe.2222.0"
Tous vos fichiers sont là.
Exemple 2 :
Votre job est "Running On" ll-jack et son "jobid" est ll-joe.1111.0
Faites un "cd /local2/run/ll-joe.1111.0"
Tous vos fichiers sont là.
Attention, depuis octobre 2003, les jobs de cri_job_type mpi
sont autorisés tourner "à cheval" sur deux noeuds. Par conséquent, les
espaces temporaires alloués pour leur exécution se trouvent
respectivement dans /dlocal/run/job-id et /dlocal/spool/job-id.
Tous les autres jobs ne sont pas autorisés à tourner "à cheval" sur deux noeuds.
Pour les limites des ressources par type de job, suivre ce lien.
Remarque :
si vous ne trouvez pas le répertoire portant comme nom le "jobid" de
votre job, il se peut qu'il vient de finir et qu'il ait été déplacé
dans le spool en attendant le rapatriement vers votre espace permanent
/work.
Que signifie le code d'erreur lors de la soumission du job ?
Lors de la soumission des jobs, une erreur fatale peut survenir. Dans ce cas elle renvoie un code qui se trouve dans le tableau ci-dessous :| Codes d'erreur | Signification |
|---|---|
| 0 | tout va bien ! |
| Erreurs liées à l'environnement | |
| 101 | l'exécution a lieu en dehors de l'environnement Loadleveler |
| 102 | utilisateur ou groupe non autorisé |
| 103 | les variables d'environnement Loadleveler sont absentes |
| 104 | les variables d'environnement $HOME_DIR et $WORK_DIR ne désignent pas des répertoires |
| 105 | l'utilisateur n'a pas les droits de lecture et d'écriture sur $HOME_DIR |
| 106 | l'utilisateur n'a pas les droits de lecture et d'écriture sur $WORK_DIR |
| Erreurs liées au prologue | |
| 110 | on a perdu le système de fichiers /local/run |
| 111 | on a perdu le système de fichiers /local/spool |
| 112 | la copie des fichiers du cri_initialdir vers l'espace temporaire s'est mal passée |
| 113 | il y a une erreur de syntaxe dans le nom du cri_initialdir (pas de ../ et de ;) |
| 114 | la variable cri_initialdir n'est pas renseignée |
| 115 | le cri_initialdir doit être un répertoire |
| 116 | le cri_initialdir n'est pas autorisé en lecture |
| 117 | il y a des liens symboliques dans l'arborescence du cri_initialdir qui ne sont jamais suivis |
| 118 | le répertoire $LOCAL_WORK_DIR ne peut pas être crée |
| 119 | le répertoire $LOCAL_SPOOL_DIR ne peut pas être crée |
| 120 | le cri_initdir est un chemin absolu qui n'est ni dans /home/.., ni dans /work/... |
| 121 | le cri_initdir n'existe pas |
| 122 | le cri_initdir est vide |
| Erreurs liées à l'épilogue | |
| 210 | crash du job durant l'exécution |
| 211 | une erreur est survenue lors du déplacement des fichiers du cri_spool vers le répertoire $LOCAL_SPOOL_DIR |
| 212 | le répertoire /work/projet/login/SPOOL n'a pu être crée |
| 213 | la création du répertoire cri_finaldir n'a pu se faire |
| 214 | il y a une erreur de syntaxe dans la variable cri_spool (pas de ../ et de ;) |
| 215 | la variable cri_spool doit être un répertoire |
Tous les codes supérieurs à 100 sont des codes CRIHAN.
A quoi servent les variables cri_initialdir et cri_finaldir ?
les calculs sont effectués dans les disques internes du noeud d'exécution et non pas dans les espaces permanents situés sur la baie FastT500 pour avoir les meilleures performances d'I/O : la bande passante de ces disques est nettement supérieure à celle de la fibre optique qui relie les noeuds à la baie.Ainsi on envoye au prologue les fichiers nécessaires au job vers le noeud d'exécution et on récupère lors de l'épilogue les fichiers résultats. Le système gère les espaces temporaires alloués dans les disques internes des noeuds pendant le job mais il ne sais pas où se trouvent les fichiers à duppliquer lors du prologue ni où il doit ramener les fichiers de résultats à l'épilogue. Ces deux localisations sont transmises à Loadleveler à l'aide respectivement des deux variables cri_initialdir et cri_finaldir.
cri_initialdir est
- soit un chemin absolu dans le $WORK_DIR (/work/projet/login/REP_ENTREE) ;
- soit un chemin relatif (./CODE/run/test_1) par rapport à l'endroit où est effectuée la soumission.
- Si le répertoire REP_SORTIE existe, les fichiers y sont directement placés : attention si un fichier existe déjà dans le répertoire, il est écrasé !!
- S'il n'existe pas, REP_SORTIE est crée et les fichiers y sont placés.
En cas d'absence ou d'erreur dans cri_finaldir, un répertoire $WORK_DIR/SPOOL/ll-joe.xxxx.0 est crée et les fichiers recopiés dedans.
Quelles sont les limites de ressources des jobs en batch ?
Seules les limites liées à la taille du cluster ou au type de l'application persistent. Le tableau suivant les reprend :
| Application / cri_job_type | Contraintes restantes |
|---|---|
| serial | 1 processeur / 32 Go de mémoire |
| mpi | 60 processeurs / 60 Go de mémoire |
| les jobs mpi ont la possibilité d'être à cheval sur les deux noeuds | |
| openmp | 32 processeurs / 32 Go de mémoire |
| gaussian | 32 processeurs / 32 Go de mémoire |
| gamess | 32 processeurs / 32 Go de mémoire |
| jaguar | 32 processeurs / 32 Go de mémoire |
Remarque :
Les 4 processeurs et 4 Go de mémoire de la partie interactive ne
peuvent jamais être prises par le batch.
Loadleveler pondère chaque soumission par rapport aux ressources
demandées : temps de présence, nombre de processus, volume mémoire. Un
poids est ainsi attribué. Ce poids permet de placer le job dans une des
trois classes (nouvellement créees et remplaçant les précédentes) :
small, medium, large. Moins le job est lourd plus il est prioritaire. Ensuite, la procédure de back filling tient compte des ressources demandées pour le lancement du job.
Par exemple, deux jobs demandant 32 processeurs pendant 24 heures ou
bien 32 Go de mémoire pendant 24 heures auront le même poids. La
formule de calcul du poids est basé sur la part de processeurs et la
part de mémoire demandées par le job par rapport aux ressources
physiques du cluster.
La formule de calcul est la suivante :
Le poids maximal autorisé actuellement est fixé à l'occupation de l'ensemble du cluster (60 processeurs ou 60 Go de mémoire) pendant 3 journées complètes ou bien un quart du cluster pendant 12 jours, etc ...
Pour d'autres informations sur la soumission batch, voir la page consacrée à loadleveler.
Que signifie (alloc) dans la sortie de llq ?
Cela signifie qu'il y a une erreur dans l'écriture du script de soumission sur la ligne
data_limit.
En effet, un caractère "espace" s'est glissé entre la quantité de
mémoire demandée et son unité. Par exemple :
# @ data_limit = 1 gb est erronée. Il faut écrire :
# @ data_limit = 1gb
Que se passe-t'il si le wall_clock limit est atteint ?
Attention : si le wall_clock_limit est atteint, l'espace disque temporaire est immédiatement détruit ainsi que son contenu (i.e. tous vos fichiers).
Il est donc important de bien évaluer le temps d'éxecution du job, quitte à le majorer dans un premier temps.
Il n'y a pas moyen de récupérer les fichiers ainsi perdus, ou de modifier la durée du job après le démarrage de delui-ci.
Que signifient les temps fournis dans le mail de fin par Loadleveler ?
Dans le mail final envoyé par Loadleveler, (si demandé par l'utilisateur dans son script), on trouve plusieurs durées temporelles qui peuvent être comprises de la manière suivante :
| Intitulé | Valeur fournie | Traduction | Signification |
|---|---|---|---|
| Real Time: | 0 05:58:36 | 0 jour 5 heures, 58 mn, 56 sec écoulées | temps "physique" , "a la montre" |
| Job Step User Time: | 1 10:01:49 | 1 jour 10 heures, 1 mn, 49 sec | temps cpu consommé |
| Job Step System Time: | 0 19:30:09 | 0 jour 19 heures, 30 mn, 9 sec | temps system consommé |
| Total Job Step Time: | 2 05:31:58 | 2 jours 5 heures, 31 mn, 58 secondes | Job Step User Time + Job Step System Time |
En cas de problème
Pensez ticket d'assistance
Pour tout problème ou question, n'hésitez pas à ouvrir un ticket d'assistance.