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, /save ?
- Quelle vision a-t-on du cluster d'IBM ?
- Que sont les large pages et les small pages ?
Configuration logicielle
- Quels types d'application sont supportés par le cluster IBM ?
- Quelles librairies scientifiques sont installées sur le cluster IBM ?
Passage cluster Power4 (joe/jack) -> cluster Power5 (william/averell)
- Quelles sont les grandes différences entre ces deux plate-formes ?
- Peut-on ré-utiliser des fichiers binaires Power4 ?
- Comment porter un code Power4 vers le cluster Power5 ?
- Correspondance des options Power4 / Power5
- Comment mesure-t-on le temps dans un programme ?
- Quelles sont les différences matérielles entre le cluster Power4 et le cluster Power5 ?
- Quelles sont les différences logicielles entre le cluster Power4 et le cluster Power5 ?
Compilation sur Power5
- Quel compilateur choisir ?
- Quelles options de compilation choisir ?
- Erreur de compilation -O2/O3 et -qcheck
Portage sur Power5
Déboguage sur Power5
- 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 ?
- Que faire si dbx refuse de lancer mon exécutable ?
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 ?
- Lecture par un programme MPI de l'entrée standard en batch ?
- Qu'est ce que le fichier hostfile ?
- Comment compiler et faire tourner un job OpenMP ?
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 ?
- Message d'erreur lors du lancement /var/loadl/execute/averell-a1.crihan.fr.771.0/...
Divers
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 de stockage, $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.
Enfin, lors de la soumission des calculs en batch, un espace de travail temporaire est alloué, au sein du système de fichier /dlocal, 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 logiciel de traitement par lots, Loadleveler.
Voir aussi les pages consacrées aux espaces de travail et aux modes interactif et batch .
Comment connaitre l'espace disque occupé dans /home, /work, /save ?
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, /work et /save 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 | 5000000 | 5500032 | 0 | none |
| indus | USR | 0 | 0 | 0 | 0 | none |
| work | USR | 4679528 | 25000960 | 25500672 | 0 | none |
Dans l'espace /home, 118262 ko sont occupés avec une limite de 5000 Mo et un maximum de 5500 Mo. 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 25000 Mo et un maximum de 25500 Mo. 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 les deux frontales p510, william et averell. Chaque frontale dispose de deux processeurs Power 5 (1.5GHz) et de 4 Go de mémoire vive. Les espaces permanents des utilisateurs (/home, /work et ) sont visibles. Le reste de la configuration, inaccessible, est dédiée au batch. L'utilisateur décide de la machine frontale sur laquelle il souhaite se connecter : willian.crihan.fr ou averell.crihan.fr .
Les jobs soumis en mode interactif prennent leurs ressources dans ces deux frontales.
Les jobs soumis en mode batch prennent leurs ressources dans l'un (ou plusieurs) des 19 noeuds p575 octo-processeurs.
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 d'une part entre l'espace permanent initial cri_initialdir et le répertoire temporaire alloué dans /dlocal ($LOCAL_WORK_DIR) et d'autre part entre le répertoire temporaire alloué dans /dlocal ($LOCAL_SPOOL_DIR) et l'espace permanent final cri_finaldir.
Voir la configuration du cluster.Que sont les large pages et les small pages ?
La mémoire physique des ordinateurs est vue au travers de page mémoire de taile fixe, en général 4 ko chacune. Lorsque l'on accède à une donnée, on accède d'abord à une page, puis à la donnée qui s'y trouve.
Le système AIX propose deux types de page, les pages de 4 ko (small pages ou SP) et les pages de 16 Mo (large pages ou LP). La mémoire des noeuds p575 est partagée entre ces deux types : il y a 10 Go de LP et 2Go de SP. En effet, seul le heap ("tas"), soit les variables globales, peut être alloué en LP, la stack ("pile") ne peut être allouée qu'en SP.
D'autre part, toute allocation mémoire réserve au moins une page en mémoire, même si elle n'est pas complètement utilisée. Il est ainsi dangereux et couteux de ne prendre que des LP car tous les scripts, les daemons système prendraient eux-aussi des LP même si ce n'est que pour quelques centaines d'octets et cela entrainerait un gros gaspillage mémoire.
Les LP ne sont pas accessibles directement, il faut que l'utilisateur soit autorisé par les administrateurs (fait par défaut) et que les exécutables soient crées ou modifiés pour qu'ils allouent des LP. Si le code est compilé sur le cluster du CRIHAN (frontales ou noeuds), AVEC les compilateurs IBM (xlf ou xlc) l'édition des liens s'en charge ; si vous ramenez un binaire, OU si vous employez un autre compilateur (par exemple gcc/g++) il est impératif de modifier les "propriétés" de l'exécutable avec la commande ldedit :
ldedit -blpdata executable .
Sans ces modifications, le programme subira une dégradation extrême des performances lors de la soumission en batch.
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) 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, Gaussian, ...) 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 cluster Power4 (joe-jack) -> cluster Power5 (william/averell)
Quelles sont les grandes différences entre ces deux plate-formes ?
Le document présente la nouvelle architecture d'un point de vue matériel et logiciel et décrit les nouveautés : cluster multi-noeuds, les large pages, les modifications pour LoadLeveler et les compilateurs.
Peut-on ré-utiliser des fichiers binaires Power4 ?
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 IBM (p690-Power4 et p575-Power5). Il n'y a donc aucun problème pour relire ces fichiers. Les fichiers objets, librairies et archives sont compatibles entre les deux clusters : il y a comptabilité ascendante.
Toutefois, il est absolument impératif de recréer les binaires, soit au moins l'édition des liens pour que leur exécution se passe normalement en mode batch.
Ainsi on peut résumer les choses :
1. si on dispose de son code source, on adapte le Makefile (-qarch=pwr[5|4] -qtune=pwr[5|4]) et on recompile le code en intégralité ;
2. si on ne dispose que des binaires, on les adapte pour les Large Pages :
Comment porter un code Power4 vers le cluster Power5 ?
Dans la mesure où le programme est écrit en respectant les règles et la norme du langage, le portage devrait s'effectuer de manière immédiate et transparente.Pour un programme qui ne respecte pas complètement la norme, il peut y avoir quelques petites modifications à apporter car ce sont des versions plus récentes des compilateurs / bibliothèques qui sont installées.
De manière générale, par exemple, (même pour un nouveau code), on peut suivre les principes énoncés ci-dessous :
- installer le code source dans le $HOME_DIR ;
- choisir un compilateur de la famille XLF (voir Quel compilateur choisir ?);
- 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 des options Power4 / Power5
On peut conserver le même fichier de compilation Makefile pour le cluster Power5.
La seule différence notable se situe dans les options d'optimisation :
Il faut prévoir, dans la mesure du possible, deux programmes exécutables. L'un est compilé avec les options -qarch=pwr5 et -qtune=pwr5 et l'autre avec -qarch=pwr4 et -qtune=pwr4.
Le choix entre le binaire pris en compte se fait au moment de l'exécution des travaux soumis à Loadleveler.
Voir la page consacrée à LoadLeveler pour les détails de la mise en oeuvre.
Les options -qarch=auto et -qtune=auto sont neutres et permettent de s'adapter à la plate-forme sous-jacente, soit a priori, les frontales de connexion MAIS attention les programmes ainsi compilés peuvent ne pas s'exécuter sur les noeuds p690.
Il est donc préférable de générer deux programmes exécutables.
Comment mesure-t-on le temps dans un programme ?
Les routines de mesure du temps sont décrites dans la page des conseils pratiques.
Quelles sont les différences matérielles entre les cluster Power4 et Power5 ?
Le cluster Power4 est constitué de deux noeuds p690 Turbo (32 processeurs Power4 à 1.9GHz et 32 Go de mémoire vive).
Le cluster Power5 est contitué de vingt-deux noeuds p575 (8 processeurs Power5 à 1.9GHz et 16 Go de mémoire). Son accès se fait au travers de deux frontales de connexion, william et averell, qui sont des bi-processeurs p510 (2 processeurs Power 5 à 1.5GHz et 4 Go de mémoire).
La compatibilité ascendante des matériels IBM fait que les fichiers objets (statiques) construits sur les p690 sont utilisables sur les p575.
Mais l'optimisation n'est pas faite pour les processeurs Power 5 pour autant, il est nécessaire de recompiler l'application.
MAIS
La configuration de la mémoire des noeuds de calcul (utilisation massive des large pages) implique que pour tous les exécutables il faut impérativement (au moins) refaire l'édition des liens sous peine de non exécution / dégradation extrême des performances.
S'il n'est pas possible de refaire l'édition des liens, on peut modifier les "propriétés" de l'exécutable avec la commande ldedit :
ldedit -blpdata executable .
Une application parallèle de type MPI peut occuper jusqu'à 16 noeuds complets, soit 128 processeurs Power5 et 160 Go de mémoire en large pages. Une application séquentielle ou parallèle à mémoire partagée (OpenMP, ...) peut occuper un noeud complet, soit 8 processeurs et 10 Go de mémoire en large pages dans le cas d'un noeud p575, soit 32 processeurs et 20 Go de Large Pages pour un p690.
La nouvelle configuration est théoriquement quatre fois plus puissante (176 processeurs Power5 vs 64 processeurs Power4) avec un gain de puissance par processeur de l'ordre de 50%. En pratique, d'autres facteurs interviennent et on constate un gain de performance global de l'ordre de 100% par processeur, soit un doublement.Quelles sont les différences logicielles entre le cluster Power4 et le cluster Power5 ?
L'environnement logiciel est très proche ; il s'agit essentiellement de versions plus récentes et/ou incompatibles avec l'architecture du cluster Power4 (commutateur Colony notamment) pour des outils liés à l'administration et la configuration du cluster.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 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.
Erreur de compilation -O2/O3 et -qcheck
Lorsque vous employez un niveau d'optimisation -O2 ou -O3 avec l'option de vérification de non dépassement des bornes de tableaux, on peut rencontrer l'erreur suivante :
* ICE with option -O2
** init === End of Compilation 1 ===
xlf_r: 1501-230 Internal compiler error; please contact your Service Representative
1501-511 Compilation failed for file init.f.
* Error for option -O3
** init === End of Compilation 1 ===
1586-346 (U) An error occurred during code generation. The code generation return code was 40.
1501-511 Compilation failed for file init.f.
Ces problèmes sont résolus en ajoutant l'option -qipa=level=0 avec -O2 et -qcheck xlf_r -c -O2 -qcheck -qipa=level=0 init.f
et en ajoutant l'option de compilation -qcheck -qipa=level=2 avec -O3 et -qcheck xlf_r -c -O3 -qcheck -qipa=level=2 init.f
En effet, pour des raisons d'implémentations techniques du backend d'optimisation du compilateur XL Fortran, les options d'optimisation sont intimement liées.
Par exemple, spécifier l'option -O5 est équivalent à spécifier l'option -O4 en même temps que -qipa=level=2
L'option -qipa (InterProcedural Analysis) permet d'améliorer les optimisations -O2 et de réaliser une analyse détaillée entre les procédures et permet d'assurer la meilleure combinaison entre vitesse de compilation et performance à l'exécution.
Si la compilation et le link sont faits dans deux phases distinctes, l'option -qipa doit être spécifiée dans les deux cas.
Le niveau d'IPA peut être précisé en utilisant la sous-option "level"
-qipa=level=x (x étant une valeur numérique comprise entre 0 et 2).
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 ;
- Ainsi on a la session de déboguage en interactif et la procédure de déboguage en soumission de travaux.
On peut aussi consulter la pages des conseils 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 ou lorsque le code sort de l'espace alloué (bogue). Pour le premier cas, il peut y avoir plusieurs causes :
- limites interactives : le shell, soit l'interpréteur de commandes, qui est l'environnement d'exécution du programme possède des limites par défaut sur les ressources consommables. Elles peuvent être trop restrictives pour le programme : on peut les relever avec la commande ulimit MAIS les frontales de connexion ne sont pas prévues pour faire de grosses exécutions en interactif, ce qui implique souvent de relancer votre test en batch car remonter les limites ne suffit pas forcément.
- 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 32 bits. 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 64 bits, 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 (avec l'option -q64, voir la page du compilateur), 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, où les types entiers sont souvent utilisés comme pointeurs et contiennent alors ces 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.
Que faire si dbx refuse de lancer mon exécutable ?
dbx est un débogueur symbolique dont l'exécutable est un binaire compilé en 32 bits. Cela impose un certain nombre de contraintes, notamment sur les ressources utilisées à l'exécution. En particulier, il impose des limites( commande ulimit) quel que soit le programme que l'on débogue. Dans le cas d'un programme compilé en 64 bits qui a un gros bloc BSS (données) les limites imposées par dbx empêche l'exécutable de démarrer en session de débogage. On a un message de la forme :
dbx programme
Type 'help' for help.
warning: cannot execute programme
reading symbolic information ...program is not active
Pour résoudre cela, il faut modifier la commande de lancement de dbx en ajoutant une option. Cela devient :
dbx -E LDR_CNTRL=MAXDATA=0x900000000 programme
On donne à dbx une plus grande limite pour stocker les données du programme en mémoire et cela fonctionne. Si la valeur donnée en exemple (ici en hexadécimal) est trop petite, on peut en mettre plus plus grande.
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 ou xprofiler 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 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 ou xprofiler.
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 : deux biprocesseurs p510 (2 processeurs power 5 cadencés à 1.5GHz, 4 Go de mémoire) L'utilisateur décide de la machine frontale sur laquelle il souhaite se connecter : willian.crihan.fr ou averell.crihan.fr.
Ces deux frontales ne sont pas destinées à réaliser de grosses exécutions en interactif. - une partie batch (traitement par lots) qui englobe les 22 noeuds p575 (8 processeurs Power5, 16 Go de mémoire). 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 sa page.
Voir aussi la page consacrée au modes interactif et 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 !
Remarque :
Lors des soumissions en batch, dans la sortie standard prévue par LoadLeveler, se trouve une ligne supplémentaire qui indique la quantité maximale de mémoire (pour les données) prise durant l'exécution PAR processus. Cette valeur est obtenue par échantillonnage. Elle peut être ré-utilisée lors des soumissions suivantes pour mieux paramétrer les besoins (data_limit) et comme un code avec des besoins inférieurs passe plus vite ....
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 2 processus) :
- la commande poe : poe ./a.out -procs 2 ;
- la variable d'environnement MP_PROCS : setenv MP_PROCS 2 puis le lancement avec ./a.out ;
- l'exécutable avec le nombre de processus : ./a.out -procs 2.
Il convient de renseigner plusieurs variables d'environnement :
- setenv MP_PROCS nbprocs
- setenv MP_EUILIB [us|ip] (selon les cas)
- setenv MP_SHARED_MEMORY yes
- setenv MP_WAIT_MODE poll
Ces initialisations sont faites par défaut lors de la soumission et sont données ici à titre indicatif !
Les commandes loadleveler pour l'exécution en mode batch sont :
- soumission : llsubmit ;
- suivi : llq ;
- arrêt : llcancel.
Voir les pages consacrées à loadleveler et aux modes de soumission des jobs.
Lecture par un programme MPI de l'entrée standard en batch ?
La prise en compte de l'entrée standard stdin diffère par rapport à celle sur le cluster power4 car l'environnement parallèle POE (MPI) a évolué.
Dorénavant l'ensemble des processus de l'application MPI reçoit l'entrée standard au lieu d'un seul. Si un seul processus lit concrètement l'entrée standard, la non lecture de l'entrée standard par les autres processus de l'application dégrade fortement les performances de votre application.
Dans ce cas il est impératif de positionner la variable d'environnement MP_STDINMODE à la valeur <rang du processus MPI qui lit l'entrée standard>. Voir aussi la manpage de poe pour le descriptif complet de la variable d'environnement (et de toutes les autres de POE).
Qu'est ce que le fichier hostfile ?
Le fichier hostfile est un fichier un fichier texte qui est utilisé par MPI lors du lancement du code en interactif. Ce fichier a la forme suivante :
william
william
averell
averell
selon la frontale que vous utilisez.
L'exécution en interactif sur une frontale occupe jusqu'aux deux processeurs de la frontale et pénalise fortement tous les autres utilisateurs connectés sur la frontale.
Merci de ne pas en abuser.
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 :
- setenv AIXTHREAD_SCOPE S
- setenv SPINLOOPTIME 1000000
- setenv YIELDLOOPTIME 1000000
- setenv OMP_NUM_THREADS 2
Ces initialisations sont faites par défaut lors de la soumission et sont données ici à titre indicatif !
Les commandes loadleveler pour l'exécution en mode batch sont :
- soumission : llsubmit ;
- suivi : llq ;
- arrêt : llcancel.
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.
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,
OpenMP,
Gaussian 03 ksh ou csh,
Gaussian 98ksh ou csh,
Jaguar 6.0(ksh ou csh),
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 ?
Il y a quatre commandes pour tout faire en batch.
- la commande llstatus -R permet de connaitre les ressources disponibles (d'après les informations en possession de Loadleveler).
- 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-william.xxxxx.0 (ou ll-averell.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. 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.
- La commande llcancel permet de supprimer une requête soumise à Loadleveler.
La syntaxe est llcancel numéro_job .
Pour les jobs MPI à cheval, il s'agit du noeud père.
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 :
Votre job est "Running On" p5-a1-n1 et son "jobid" est william.2222.0
Faites un "cd /dlocal/run/william.2222.0"
Tous vos fichiers sont là.
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 ($LOCAL_SPOOL_DIR) en attendant le rapatriement vers votre espace permanent cri_finaldir.
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 des codes d'erreur dans la page consacrée à Loadleveler.
A quoi servent les variables cri_initialdir et cri_finaldir ?
les calculs sont effectués dans des répertoires temporaires crées dans un système de fichiers partagé par tous les noeuds, le /dlocal.Ainsi on envoye au prologue les fichiers nécessaires au job vers ce répertoire et on récupère lors de l'épilogue les fichiers résultats spécifiés par l'utilisateur.
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 à dupliquer 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 un chemin absolu
- soit dans le $HOME_DIR (/home/projet/login/REP_ENTREE) ;
- soit dans le $WORK_DIR (/work/projet/login/REP_ENTREE) .
cri_finaldir est un chemin absolu
- soit dans le $HOME_DIR (/home/projet/login/REP_SORTIE) ;
- soit dans le $WORK_DIR (/work/projet/login/REP_SORTIE) .
qui peut ne pas exister lors de 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.
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. Un tableau récapitule ces limites dans la page Loadleveler.
On peut paramétrer les données suivantes :
- cri_total_tasks : nombre de processus;
- wall_clock_limit : temps de présence (pour l'application) ;
- data_limit : mémoire (pour les données globales au processus) ;
- stack_limit : mémoire (pour les données locales au processus) ;
- core_limit : espace disque pour les fichier core (par processus).
Remarque :
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
cinq classes : xsmall, small, medium, large, xlarge. 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.
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 ?
Un changement dans la politique de gestion des espaces temporaires $LOCAL_WORK_DIR est intervenu.
Dorénavant, si le wall_clock_limit est atteint, l'espace disque temporaire bénéficie d'un délai de trois semaines avant sa destruction automatique et définitive.
Ce délai pourra être raccourci si le remplissage du système de fichiers /dlocal est trop important.
Que signifient les temps fournis dans le mail de fin par Loadleveler ?
Dans le mail final envoyé par Loadleveler, (si demandé par l'utilisateurdans 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 |
Message d'erreur lors du lancement /var/loadl/execute/averell-a1.crihan.fr.771.0/...
La soumission se passe normalement mais le job n'apparait pas dans le suivi et l'erreur standard contient la ligne suivante
ksh: /var/loadl/execute/averell-a1.crihan.fr.771.0/
Cette erreur peut provenir d'un mauvais chemin vers le shell utilisé dans l'en-tête du script de soumission LL. Il faut spécifier correctement le chemin :
/usr/local/bin/tcsh
/usr/local/bin/bash
/usr/bin/csh
/usr/bin/sh
Divers
Comment changer mon shell ?
La commande chsh permet de changer son shell, de manière permanente :GM-PWR5 % chsh
Current available shells:
/usr/bin/ksh
/usr/bin/sh
/usr/bin/bsh
/usr/bin/csh
/usr/local/bin/tcsh
/usr/local/bin/bash
gm's current login shell:
/usr/local/bin/tcsh
Change (yes) or (no)? >
En cas de problème
Pensez ticket d'assistance
Pour tout problème ou question, n'hésitez pas à ouvrir un ticket d'assistance.