Slides - indico in2p3

Transcription

0<+>0
Rappel
MPI +
GE
Annexes
Le service de calcul parallèle avec GridEngine
Bernard CHAMBON
Centre de Calcul de l’IN2P3, Lyon - France
février 2012
0<+>0
Sommaire
Rappel
MPI +
GE
Annexes
Rappel
• MPI
• Configuration du cluster
• Spécificité de notre environnement
• Qui sont nos utilisateurs
MPI avec GridEngine
• Cas d’OpenMPI
• Cas MPICH2
• Cas MPI-Intel
Annexes
0<+>0
Rappel
MPI +
GE
Annexes
Rappel sur MPI
Message Passing Interface
Norme pour exploiter machines à mémoire partagée ou distribuées
Succès de MPI dû à portabilité et performance
Langage : C/C++ et Fortran
MPI-2 (depuis 1997)
Implémentations
OpenMPI
MPICH2, MVAPICH2 (pour infiniband) : Argonne National Laboratory
MPI-Intel
A propos d’OpenMP
Open Multi Processing = pour machines à mémoire partagée
Une même machine au CC, on tombe alors dans le cas des jobs dit "multicores"
(mais des utilisateurs souhaitent mixer du MPI avec du OpenMP : ex Planck)
0<+>0
Rappel
MPI +
GE
Annexes
Rappel de la configuration du cluster
Configuration machines (janvier 2012)
16 processors (2 CPU, 8 cores), Xeon E5540 @ 2.53GHz, 48 GB ram, 2 interfaces
réseau 1|10 Gb/s
Cluster de 64 machines ⇒ 1024 cores (=1024 slots)
Configuration réseau
2 interfaces réseau : ccwpge00[01-64] (1Gb/s) et ccwpge00[01-64]p (10Gb/s)
Le 2eme interface est dédié au besoins du calcul ; non accessible au ssh, GE n’en
a pas la connaissance
Disponibilité
Via GridEngine uniquement et en mode batch (pas d’accès interactif)
Réservé aux utilisateurs autorisés (autorisation via GE)
En mode "tight integration" (détaillé plus loin)
Instance de GE
Une seule instance de GridEngine pour les jobs séquentiels, parallèles, interactifs
0<+>0
Rappel des spécificités au CC
1/2
Rappel
MPI +
GE
Annexes
Token AFS
Les jobs parallèles doivent disposer d’un token AFS, y compris pour les tâches
esclaves
Cette demande est implicitement satisfaite, lorsqu’on est en mode tight
integration, ce qui est notre cas.
Redirection des stdout | stderr
Le mécanisme de redirection de l’écriture des sdtout|err localement au worker
n’est pas actif 1
En conséquence, les sdtout|err des jobs sont écrits, en cours d’exécution, dans
$HOME de l’utilisateur (si rien n’est spécifié), ou dans le répertoire ad-hoc
suivant les options -wd | -cwd | -o | -e | -j
1. Les prolog|epilog (intègrent ce mécanisme), non déployés sur les WNs parallèles, pcq WNs esclaves
0<+>0
Rappel des spécificités au CC
2/2
Rappel
MPI +
GE
Annexes
Espace ’scratch’ ($TMPDIR)
Pour la même raison 1 que précédemment, le mécanisme de contrôle, par quota,
de l’espace scratch n’est pas disponible
En conséquence l’espace disque $TMPDIR est de taille non limitée
$TMPDIR est accessible partout (WN maitre et esclave).
Accès à l’espace semi-permanent (/sps)
Contrôle inhibé pour cause d’absence d’epilog 1
⇒ /sps disponible sans condition sur les WNs parallèles (ccwpgeX)
Autre ?
1. Les prolog|epilog (intègrent ce mécanisme), non déployés sur les WNs parallèles, pcq WNs esclaves
0<+>0
Rappel des spécificités liées à GridEngine
Expression en CPU, mémoire, complex de régulation, queues d’exécution
Rappel
MPI +
GE
Annexes
CPU, mémoire et complex de régulation
L’expression en CPU et mémoire ne doit pas intégrer le nombre de tâches.
L’espace scratch $TMPDIR n’est pas limité
L’expression en complex de régulation ne doit pas intégrer le nombre de tâches,
mais la comptabilité GE (visible par qquota) en tient compte
Pour plus de détail :
http://cc.in2p3.fr/JobsMulticoresEtParalleles
Queues et objets parallèles(=PE)
Queue parallèles : pa_short | medium | long
associées aux multiples PE openmpi | mpich2 | mpiintel
⇒ spécification, à la soumission, de l’objet PE et de la queue
Les jobs tournent sur des ccwpgeX (p = parallèle)
Ex : qsub -pe mpich2 16 -q pa_short ...
Queue multicores : mc_short | medium | long | longlasting
associées au PE multicores
Objet PE uniquement pour l’allocation des slots, les jobs tournent sur des
ccwsgeX (S = séquentiel)
Spécification de la queue ET de l’objet PE à la soumission
Ex : qsub -pe multicores 16 -q mc_short ...
0<+>0
Nos utilisateurs
Rappel
MPI +
GE
Annexes
Plank et Qcd :
besoin = centaines de coeurs
Qcd : mpiintel
Plank : openmpi et openMP+openmpi
Autres groupes
Strasbourg, Subatech (ou Dchooz) : mpich2
Cral : mpich2, openmpi maintenant
Besoin en multicores
BQS : parallèle@Pistoo → GE : multicores@ccwsgeX
Autres besoins en multicores
Besoins de machines, en exclusivité, pour cms, lhcb, atlas
(queues multicores sur des hostgroups)
1. Infos de Rachid - merci
0<+>0
Les implémentations disponibles au CC
Rappel
MPI +
GE
Annexes
OpenMPI
Version 1.4.2 : facile
MPICH2
Version courante = 1.0.8p1 : délicat
Nouvelle version 1.4.1p1 (framework hydra) : plus facile
MPI-Intel
Version courante 3.0 en 32 bits (bin/) et 64 bits (bin64/) : La voie est tracée...
Version 4.x (framework hydra ?) : devrait être facile
0<+>0
Rappel
MPI +
GE
Annexes
OpenMPI en mode manuel : Syntaxe
Lancement "manuel" entre 2 machines (ccwpge0061 | 62)
Worker maitre
>more /tmp/machines
ccwpge0061 slots=1
ccwpge0062 slots=3
> mpiexec --machinefile /tmp/machines -launch-agent /usr/local/openmpi/bin/orted
> bchambon@ccwpge0062’s password: ...
(Session ssh sur ccwpge0062 pour lancement de orted)
-np 4 bin/advance_test (*)
> ps -e f -o user,pid,ppid,command
bchambon 18866 18865 |
\_ -tcsh
bchambon 8109 18866 |
\_ mpiexec --machinefile /tmp/machines -launch-agent /usr/local/openmpi/bin/orted
bchambon 8112 8109 |
\_ bin/advance_test
(*)
Nécessité de positionner
LD_LIBRARY_PATH (à /usr/local/openmpi/lib) dans un
.profile | .cshrc
Worker esclave
> ps -e f -o user,pid,ppid,command
bchambon 15796
1 /usr/local/openmpi/bin/orted --daemonize -mca ess env -mca orte_ess_jobid 1225654272 -mca orte_es
bchambon 15797 15796 \_ bin/advance_test
0<+>0
OpenMPI en mode manuel : débit réseau
Avec mpiexec --mca btl_tcp_if_include eth0 --machinefile ...
Rappel
MPI +
GE
Annexes
> dstat -n -N eth0,eth2
--net/eth0- --net/eth2recv send: recv send
1323k 118M:
0
0
1321k 118M:
0
0
1321k 118M:
0
0
On "sature" l’interface eth0, 1Gb/s
Avec mpiexec --mca btl_tcp_if_include eth2 --machinefile ... > /dev/null
19k 4046B:2287k 1064M
19k 3936B:2302k 1064M
19k 3634B:2296k 1064M
16k
57k:2315k 1063M
On "sature" l’interface eth2, 10Gb/s
Sans précision particulière : avec mpiexec --machinefile ... > /dev/null
1289k 118M: 251k 121M
1295k 118M: 244k 115M
1290k 118M: 258k 118M
Les deux interfaces sont utilisés, pour un max de ∼240MB/s
120 (eth0 saturé) + 120 (eth2 symétrique de eth0 ?) : à comprendre
0<+>0
Rappel
MPI +
GE
Annexes
OpenMPI dans GridEngine
Disponibilité en tight intégration
Le support de Grid Engine est intégré à OpenMPI (v >= 1.2), par compilation
avec l’option "–with-sge"
En conséquence l’objet PE est très simple
l’objet PE (à commenter)
>qconf -sp openmpi
pe_name
slots
user_lists
xuser_lists
start_proc_args
stop_proc_args
allocation_rule
accounting_summary
...
openmpi
1024
NONE
NONE
/bin/true
/bin/true
round_robin
FALSE
Exécution du code
Après positionnement des diverses var. d’env. l’exécution du code se fait par :
mpiexec
-n $NSLOTS ./bin/atest
Choix de réseau (infiniband | tcp) et l’interface (eth0 | eth2) via les paramètres
MCA (Modular Component Architecture )
Ex : mpiexec –mca btl_tcp_if_include eth2 ...
Exemples avec visualisation des processus
0<+>0
OpenMPI dans GridEngine : hiérarchie des process
Worker maitre
Rappel
MPI +
GE
Annexes
> ps -e f -o user,ppid,pid,pgrp,command
root
1 6531 6531 /opt/sge/bin/lx24-amd64/sge_execd
root
6531 6579 6531 \_ /bin/sh /usr/bin/load.sh
root
6531 14669 14669 \_ /opt/sge/bin/lx24-amd64/sge_shepherd -bg
root
14669 14723 14669
\_ /opt/sge/bin/lx24-amd64/sge_coshepherd /opt/sge/util/set_token_cmd bchambon 172800
bchambon 14669 14725 14725
\_ /bin/ksh /var/spool/sge/ccwpge0003/job_scripts/1031421
bchambon 14725 14727 14725
\_ /usr/local/openmpi/bin/mpiexec --mca btl ûdapl,openib --mca btl_tcp_if_include
...
bchambon 14727 14755 14725
\_ /opt/sge/bin/lx24-amd64/qrsh -inherit -nostdin -V ccwpge0008.in2p3.fr set
bchambon 14727 14756 14725
\_ /opt/sge/bin/lx24-amd64/qrsh -inherit -nostdin -V ccwpge0009.in2p3.fr set
bchambon 14727 14824 14725
\_ ./bin/atest
bchambon 14727 14825 14725
\_ ./bin/atest
Worker esclave
root
root
root
bchambon
bchambon
bchambon
bchambon
1
6137
16060
16060
16076
16083
16252
6137
16060
16075
16076
16083
16252
16253
6137 /opt/sge/bin/lx24-amd64/sge_execd
16060 \_ /opt/sge/bin/lx24-amd64/sge_shepherd -bg
16060
16076
\_ /opt/sge/utilbin/lx24-amd64/qrsh_starter /var/spool/sge/ccwpge0009/active_jobs/1031
16083
\_ tcsh -c set path = ( /usr/local/openmpi/bin $path ) ; if ( $?LD_LIBRARY_PATH =
16083
\_ /usr/local/openmpi/bin/orted -mca ess env -mca orte_ess_jobid 2186543104 -m
16083
\_ ./bin/atest
A noter
Les process sont tous rattachés au shepherd (⇒ tight integration)
La disponibilité des tokens AFS est assuré implicitement (coshepherd)
Unicité du process groupID
Le qrsh -inherit ...
0<+>0
Rappel
MPI +
GE
Annexes
MPICH2 dans GridEngine
Avec la version courante du CC (=1.0.8x)
Nécessite le lancement préalable d’un env. d’exécution (daemon mpd)
Cette opération peut se faire via mpdboot, script dans lequel on peut passer en
paramètre un fichier de machines et une "rsh" commande
C’était la solution adopté dans BQS, (on avait défini un bqsrsh = rsh unix avec
obtention d’un token AFS (qtoken load))
Cette séquence était spécifiée dans le script de l’utilisateur (BQS fournissant les
fichiers de machines)
mpdboot -f machinefile --rsh=bqsrsh
mpiexec -f machinefile ...
mpdallexit
GridEngine fonctionne différemment, à savoir :
Le lancement du contexte d’exécution est réalisé dans le startup de l’objet PE
(n’est à faire dans le job)
Il est possible de demander l’exécution d’une remote commande via qrsh -inherit,
qui à pour atout d’associer la tâche remote à la hiérarchie des process d’un job,
sur WN esclave, pour tight intégration
qrsh -inherit hostname command
Utilisation de mpd
On va donc utiliser, non pas mpdboot, mais directement la commande mpd et
sans oublier de préciser l’interface réseau utilisé (–ifhn)
0<+>0
Exemple de lancement "manuel" entre 2 machines (ccwpge0001 | 02)
Rappel
MPI +
GE
Annexes
ccwpge0001
①
> mpd --ifhn=ccwpge0001 --daemon --echo
mpd_port=60438
> mpdtrace -l
ccwpge0001_60438 (134.158.175.1)
ccwpge0002
②
> mpd -h ccwpge0001 -p 60438 --ifhn=ccwpge0002 --daemon
mpd_port=58581
> mpdtrace -l
ccwpge0002_58581 (134.158.175.2)
ccwpge0001_60438 (134.158.175.1)
③
> mpdtrace -l
ccwpge0001_60438 (134.158.175.1)
ccwpge0002_58581 (134.158.175.2)
④
>more /tmp/machines
ccwpge0001:1 ifhn=ccwpge0001
ccwpge0002:1 ifhn=ccwpge0002
>mpiexec -machinefile /tmp/machines -n 2 ./bin/atest
We will exchange a buffer of 10 MB
Let’s iterate once again, master_iter = 10
Let’s iterate once again, slave_iter = 10
⑤
>dstat -n -N eth0,eth2
0
0 :
0
0
117M 838k:
0
0
117M 1272k:
0
0
117M 1322k:
0
0
117M 1270k:
0
0
117M 1040k:
0
0
Table 1: Lancement manuel d’un code mpich2
0<+>0
Maintenant qu’on sait ce qu’il faut faire, on va pouvoir :
Rappel
MPI +
GE
Annexes
Définir comment le faire
Avec l’aide de "qrsh -inherit", on va intégrer la séquence des commandes
mpd --ifhn ; mpdtrace -l (master), puis mpd -h -p --ifhn (slave) dans un script
Ce sera startmpich2.sh, exécuté au startup de l’objet PE
Définir un objet PE
>qconf -sp mpich2
pe_name
start_proc_args
stop_proc_args
mpich2
/usr/local/products/sge/mpich2_mpd/startmpich2.sh
/usr/local/products/sge/mpich2_mpd/stopmpich2.sh
$pe_hostfile
...
Notez la disponibilité du fichier de machines via la pseudo variable $pe_hostfile
Plus en détail
startmpich2.sh utilise une commande qui invoque le rsh de GE
Plus précisement
execvp /usr/local/products/sge/mpich2\_mpd/rsh
Avec /usr/local/products/sge/mpich2_mpd/rsh :
$SGE_ROOT/bin/$ARC/qrsh -inherit -V -nostdin $rhost $cmd
En pratique
Ce travail a été fait et est opérationnel, y compris pour utiliser le 2eme interface
(voir annexe pour la syntaxe des commandes et le format du fichier de machines)
0<+>0
MPICH2 dans GridEngine : Hiérarchie des process
Worker maitre (ccwpge0015)
Rappel
MPI +
GE
Annexes
root
root
root
23105 23118 23105
bchambon 23105 23119 23119
bchambon 23119 23128 23128
\_ tcsh -c mpd --ifhn=ccwpge0015p
bchambon 23128 23295 23128
\_ python2.4 mpd --ifhn=ccwpge0015p
bchambon 23295 23380 23380
bchambon 23380 23383 23383
|
\_ ./bin/atest
bchambon 23295 23381 23381
bchambon 23381 23382 23382
\_ ./bin/atest
bchambon
1 23097 23029 qrsh -inherit -V ccwpge0015 mpd --ifhn=ccwpge0015p
bchambon
1 23300 23029 qrsh -inherit -V ccwpge0011 mpd -h ccwpge0015 -p 48312 --ifhn=ccwpge0011p
bchambon
1 23302 23029 qrsh -inherit -V ccwpge0012 mpd -h ccwpge0015 -p 48312 --ifhn=ccwpge0012p
Worker esclave (ccwpge0026)
root
root
root
bchambon
bchambon
bchambon
bchambon
bchambon
bchambon
bchambon
1
6023
4506
4506
4519
4526
4695
4698
4695
4699
6023
4506
4518
4519
4526
4695
4698
4700
4699
4701
4506
4519
4526
\_ tcsh -c mpd -h ccwpge0015 -p 48312 --ifhn=ccwpge0026p
4526
\_ python2.4 mpd -h ccwpge0015 -p 48312 --ifhn=ccwpge0026p
4698
4700
|
\_ ./bin/atest
4699
4701
\_ ./bin/atest
A noter
Les process sont rattachés au shepherd (⇒ tight integration)
Attention aux qrsh -inherit en mode orphelin
Attention aux process group ID différents pour les process mpd
0<+>0
Rappel
MPI +
GE
Annexes
MPICH2 dans GridEngine : Tout baigne ou presque...
Multiplicité des process group ID des daemons mpd
Conséquence avec qdel (KILL -9 -pgrp)
Parade par mise en oeuvre d’un script en "terminate method" (basé sur le
additionnal groupID)
car, au fait, le additionnal groupID non opérationnel avec les tâches lancées par
qrsh, quelle poisse !...
Process utiles en fils de 1
Chasse aux zombies adaptée avec filtrage sur pattern "qrsh -inherit"
Stabilité des process mpd : long à solutionner...
Il est apparu des soucis d’instabilité des process mpd, en cours d’exécution du job
Problèmes rencontrés par nos utilisateurs et confirmés par nos essais
L’instabilité apparaissait plus ou moins rapidement selon le nombre de tâches
demandées (mais à priori pas selon le nombre de machines)
message d’erreur typique :
cwpge0026_39438 (reenter_ring 825): reenter_ring rc=0 after numTries=1
ccwpge0026_39438 (handle_rhs_input 1098): back in ring
...
ccwpge0001_48492 (handle_lhs_challenge_response 1052): INVALID msg for lhs response msg=:{}:
ccwpge0017_49314 (connect_rhs 973): invalid challenge from 134.158.175.30 39759: {}
ccwpge0017_49314 (enter_ring 868): rhs connect failed
ccwpge0026_39438 (handle_rhs_input 1093): lost rhs; re-entering ring
ccwpge0026_39438 (connect_lhs 916): bad generation from lhs; lhsgen=2 mygen=3
ccwpge0026_39438 (enter_ring 855): lhs connect failed
Solution : le framework hydra
0<+>0
Rappel
MPI +
GE
Annexes
MPICH2 dans GridEngine : Le framework Hydra
Présentation
Framework d’exécution qui jette aux oubliettes le daemon mpd
Ce framework intègre de nombreux ressources managers dont GridEngine, cool !
Compilation et installation de mpich2 1.4.p1 (hydra : mpich2 1.2, je crois)
⇒ Simplification
L’objets PE est simplifié à l’extrême, les scripts pe_start | stop ne sont plus
nécessaire (modèle identique à OpenMPI)
Choix du RM par l’option -rmk (RM Kernel)
Choix de l’interface réseau -iface
Pas nécessaire de spécifier le fichier de machines (-f machinefile)
Ex : mpiexec -rmk sge -iface eth2 ./bin/advance_test
Compilation et disponibilité
Version mpich2 1.4.1p1 installée
Mise à disposition de /usr/local/mpich2/hydra/ (compilé avec gcc, -O2, -m64)
(Procédure décrite dans le elog de GE)
Essai en mode manuel et à travers Grid Engine
0<+>0
MPICH2 - Hydra : mode manuel (connexion ssh)
sur le WN maître (ccwpge0061)
Rappel
MPI +
GE
Annexes
>more /tmp/machines
ccwpge0061:1
ccwpge0062:5
>mpiexec -verbose -f /tmp/machines -iface eth2 -n 6 bin/advance_test
>ps ...
\_ mpiexec -verbose -f /tmp/machines -iface eth2 -n 6 bin/advance_test
\_ /afs/in2p3.fr/home/b/bchambon/mpich2-1.4/bin/hydra_pmi_proxy --control-port 10.158.175.61:44699 --debug --rmk
|
\_ bin/advance_test
\_ /usr/bin/ssh -x ccwpge0062 "/afs/in2p3.fr/home/b/bchambon/mpich2-1.4/bin/hydra_pmi_proxy" --control-port 10.15
sur le WN esclave (ccwpge0062)
> ps ...
\_ tcsh -c "/afs/in2p3.fr/home/b/bchambon/mpich2-1.4/bin/hydra_pmi_proxy" --control-port 10.158.175.61:44699 --debug \_ /afs/in2p3.fr/home/b/bchambon/mpich2-1.4/bin/hydra_pmi_proxy --control-port 10.158.175.61:44699 --debug --rmk
\_ bin/advance_test
\_ bin/advance_test
\_ bin/advance_test
\_ bin/advance_test
\_ bin/advance_test
Débit réseau (sur ccwpge0061)
4825B 110k:2021k 994M
1026B
32k:2041k 1007M
1382B
28k:2035k 1002M
630B
28k:2039k 1004M
1102B
27k:2035k 1001M
0<+>0
MPICH2 - Hydra : mode batch (= via GridEngine)
Rappel
MPI +
GE
Annexes
root
root
root
bchambon
bchambon
bchambon
bchambon
bchambon
bchambon
...
1
6079
7952
7952
7967
7968
7969
7968
7968
6079
7952
7965
7967
7968
7969
7977
7970
7971
7952
7967
\_ /bin/ksh /var/spool/sge/ccwpge0062/job_scripts/1720021
7967
\_ mpiexec -rmk sge -iface eth2 -n 8 ./bin/advance_test
7967
\_ /afs/in2p3.fr/home/b/bchambon/mpich2-1.4/bin/hydra_pmi_proxy --control-port
7967
|
\_ ./bin/advance_test
7967
\_ /opt/sge/bin/lx24-amd64/qrsh -inherit -V ccwpge0061.in2p3.fr "/afs/in2p3.fr
7967
\_ /opt/sge/bin/lx24-amd64/qrsh -inherit -V ccwpge0033.in2p3.fr "/afs/in2p3.fr
> ps -e f
root
root
root
bchambon
bchambon
bchambon
bchambon
-o user,ppid,pid,pgrp,command
7532 7544 7532
7532 7545 7545
7545 7552 7552
\_ tcsh -c "/afs/in2p3.fr/home/b/bchambon/mpich2-1.4/bin/hydra_pmi_proxy" --contro
7552 7720 7552
\_ /afs/in2p3.fr/home/b/bchambon/mpich2-1.4/bin/hydra_pmi_proxy --control-port
7720 7721 7552
\_ ./bin/advance_test
A noter
Belle hiérarchie de process (on est bien en tight integration)
Plus de process orphelin
Unicité du process group ID
La partie est gagnée ou presque...
0<+>0
Rappel
MPI +
GE
Annexes
MPICH2 - Hydra : Stabilité (=f(numTasks))
1/2
Il est apparu un soucis, avec fréquence d’erreur liée aux nombre de tâches
¿ MPICH2 ?, compilation ?, configuration ?
Mode batch
Tests sur 10 jobs (5000 itérations par job), avec successivement 16, 32, 48 et 64
tâches
nombre de tâches
16
32
48
64
taux d’échec (x/10)
0
0
6/10
7/10
Table 2: Stabilité suivant le nombre de tâches
Message d’erreur typique :
pmiserv\_cb.c:215 : assert (!closed) failed
mpiu\_shm\_wrappers.h at line 889: seg\_sz > 0
Mode manuel
Soucis transposé en un bout de code manuel ⇒ soucis ssi ≥ 153 tâches !
>mpiexec -np 153 bin/advance_test
Assertion failed in file /scratch/BC/mpich2-1.4.1p1/src/util/wrappers/mpiu_shm_wrappers.h at line 889: seg_sz > 0
internal ABORT - process 0
[proxy:0:0@ccwpge0061] send_cmd_downstream (./pm/pmiserv/pmip_pmi_v1.c:80): assert (!closed) failed
[proxy:0:0@ccwpge0061] fn_get (./pm/pmiserv/pmip_pmi_v1.c:349): error sending PMI response
[proxy:0:0@ccwpge0061] pmi_cb (./pm/pmiserv/pmip_cb.c:327): PMI handler returned error
[proxy:0:0@ccwpge0061] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status
0<+>0
MPICH2 - Hydra : Stabilité (=f(numTasks))
2/2
Rappel
MPI +
GE
Annexes
Travail avec la liste : mpich-discuss
De nombreux essais et beaucoup de temps passé ... jusqu’à :
Obtention d’un patch réglant un soucis relatif à l’allocation des segments de
mémoire partagée ⇒ suppression du problème lié aux nombres de tâches
Pointage d’un autre soucis lié à l’utilisation de -iface ⇒ deuxième patch de
correction (+ rapide), ouf !
Essais avec un grand nombre de slots
Testé avec plusieurs centaines de tâches, pendant plusieurs heures ⇒ ok
Essais via le code des utilisateurs
En cours depuis 23 janvier. Avis de Rachid ?
Conclusion
Mpich2 1.4p1 devient la version courante
Complètement "intégré" à Grid Engine, comme avec d’autres RM
0<+>0
Rappel
MPI +
GE
Annexes
MPI-Intel en mode manuel
Avec la version courante du CC (=3.0)
N’est pas intégrée avec GridEngine
Lancement analogue au modèle défini pour MPICH2 v1.x (NON hydra)
Voir annexe pour détails de syntaxe (et mesure débit réseau eth0 | eth2)
Transcription en script associé au pe_start de l’objet PE
>qconf -sp mpiintel_eth0
pe_name
mpiintel_eth0
start_proc_args
/usr/local/products/sge/mpiintel/startmpiintel.sh \
-catch_rsh $pe_hostfile /usr/local/intel/mpi/3.0/
stop_proc_args
...
allocation_rule
$round_robin
Attention
Le choix de l’interface (eth0 | eth2) est fait au lancement de mpd
⇒ définition de deux objets PE : mpiintel_eth0 | _eth2
⇒ Le choix de l’interface se fait au moment du qsub (et non pas dans le script)
Exécution du code
mpiexec -machinefile $TMPDIR/machines -n $NSLOTS
./bin/atest
Nécéssité d’avoir un fichier mpd.hosts (même vide)
Utiliser python 2.4 (2.6 génère des warning de depreciation)
0<+>0
MPI-Intel dans GridEngine : Hiérarchie des process
Rappel
MPI +
GE
Annexes
root
root
root
23495 23509 23495
bchambon 23495 23510 23510
bchambon 23510 23519 23519
\_ tcsh -c /usr/local/intel/mpi/3.0//bin/mpd --ifhn=ccwpge0062
bchambon 23519 23688 23519
\_ /usr/local/bin/python -W ignore::DeprecationWarning /usr/local/intel/mpi/3.
bchambon 23688 23723 23723
\_ /usr/local/bin/python -W ignore::DeprecationWarning /usr/local/intel/mp
bchambon 23723 23756 23756
|
\_ bin/advance_test
bchambon 23688 23724 23724
bchambon 23724 23741 23741
|
\_ bin/advance_test
...
bchambon
1 23487 23461 /opt/sge/bin/lx24-amd64/qrsh -inherit -V ccwpge0062 /usr/local/intel/mpi/3.0//bin/mpd --ifh
bchambon
1 23697 23461 /opt/sge/bin/lx24-amd64/qrsh -inherit -V ccwpge0061 /usr/local/intel/mpi/3.0//bin/mpd -h cc
root
root
root
22378 22391 22378
bchambon 22378 22392 22392
bchambon 22392 22399 22399
\_ tcsh -c /usr/local/intel/mpi/3.0//bin/mpd -h ccwpge0062 -p 38948 --ifhn=ccwpge0
bchambon 22399 22569 22399
\_ /usr/local/bin/python -W ignore::DeprecationWarning /usr/local/intel/mpi/3.
bchambon 22569 22580 22580
bchambon 22580 22599 22599
|
\_ bin/advance_test
bchambon 22569 22581 22581
bchambon 22581 22600 22600
|
\_ bin/advance_test
A noter
Les process sont rattachés au shepherd (⇒ tight integration)
Attention aux qrsh -inherit en mode orphelin et aux process group ID différents
0<+>0
MPI-Intel dans GridEngine : Conclusion
Rappel
MPI +
GE
Annexes
La version courante (=3.0), disponible via Grid Engine
Testée rapidement, et jusqu’à 256 slots, sur les deux interfaces
Garder en mémoire les problématiques
des process orphelins (chasse aux zombie avec filtrage sur pattern "qrsh -inherit")
des process groupID différents (script de nettoyage en terminate_method)
Version 4.x
Semble intégrer le framework Hydra qui apporte l’intégration avec GE
Besoins ?
Licence ?
0<+>0
Rappel
MPI +
GE
Annexes
Conclusion générale
Disponibilités
Les 3 implémentations disponibles au CC sont dispo via Grid Engine
Vérification faite de l’utilisation du 2eme interface
Pour continuer à explorer...
Job2core binding
Checkpoint
Ces 2 points déjà explorés avec les jobs séquentiels
Merci à Mattieu, Rachid, Suzanne
Visualisation des jobs parallèles
https://cctools.in2p3.fr/astreinte/GE/JobsSummary/RJS.xml
Démo ?
Exemple de construction d’une image (1024x1024) calculée via povray
De �1h si calcul monocoeur à �60 s (tâche la plus longue) si découpage en 256
tranches (tâches)
Nombre de tâches
Plus longue tâche (⇒ durée du job)
1
3700
32
226
64
130
128
91
256
63
Table 3: Evolution de la durée (s) de la plus longue tâche, en fonction du nombre de tâches
0<+>0
Annexes
Rappel
MPI +
GE
Annexes
Lancement manuel d’un code MPICH2 utilisant le deuxième interface (eth2)
Lancement manuel d’un code MPI-Intel utilisant le premier interface (eth0)
Lancement manuel d’un code MPI-Intel utilisant le deuxième interface (eth2)
Memo MPI-Intel
Autres essais
0<+>0
MPICH2 et eth2
Lancement "manuel" d’un code mpich2 utilisant le 2eme interface réseau
Rappel
MPI +
GE
Annexes
ccwpge0061
ccwpge0062
> mpd --ifhn=ccwpge0061p --daemon --echo
mpd_port=50712
>mpdtrace -l
ccwpge0062_56112 (10.158.175.62)
> mpd -h ccwpge0061 -p 50712 --ifhn=ccwpge0062p --daemon
mpd_port=56112
>mpdtrace -l
ccwpge0062_56112 (10.158.175.62)
ccwpge0061_50712 (10.158.175.61)
>mpdtrace -l
ccwpge0061_50712 (10.158.175.61)
ccwpge0062_56112 (10.158.175.62)
>more machines.eth2
(*)
ccwpge0061p:1 ifhn=ccwpge0061p
ccwpge0062p:1 ifhn=ccwpge0062p
> mpiexec -machinefile /tmp/machines.eth2 -n 2 bin/atest
(*)
Prêter attention au format du fichier machines.eth2
(doit contenir les noms de machines en ’p’)
0
0 :
0
0
844B
23k: 968M 1912k
402B
24k: 967M 1912k
70B
67k: 968M 1914k
134B
24k: 968M 1914k
503B
21k: 968M 1914k
Table 4: mpich2 utilisant le 2eme interface réseau (10Gb/s)
0<+>0
MPI-Intel et eth0
Lancement "manuel" d’un code mpi-intel utilisant le 1er interface réseau
Rappel
MPI +
GE
ccwpge0061
ccwpge0062
>mpd --daemon --echo
mpd_port=34340
>mpdtrace -l
ccwpge0061_34340 (134.158.175.61)
>mpd -h ccwpge0061 -p 34340 --daemon --echo
mpd_port=34434
>mpdtrace -l
ccwpge0062_34434 (134.158.175.62)
ccwpge0061_34340 (134.158.175.61)
Annexes
>mpdtrace -l
ccwpge0061_34340 (134.158.175.61)
ccwpge0062_34434 (134.158.175.62)
>more /tmp/machines
ccwpge0061:1
ccwpge0062:1
>mpiexec -machinefile /tmp/machines
>mpdallexit
-n 2 bin/atest
117M 2115k:
0
0
116M 2107k:
0
0
116M 2098k:1088B 0
116M 2105k:
0
0
116M 2099k:
0
0
>mpdallexit
Table 5: mpi-intel utilisant le 1er interface réseau (1Gb/s)
0<+>0
MPI-Intel et eth2
Lancement "manuel" d’un code mpi-intel utilisant le 2eme interface réseau
Rappel
MPI +
GE
ccwpge0061
ccwpge0062
>mpd --ifhn=ccwpge0061p --daemon --echo
mpd_port=41843
>mpdtrace -l
ccwpge0061_41843 (10.158.175.61)
>mpd -h ccwpge0061 -p 41843 --ifhn=ccwpge0062p --daemon --echo
mpd_port=55445
Annexes
>mpdtrace -l
ccwpge0062_55445 (10.158.175.62)
ccwpge0061_41843 (10.158.175.61)
>mpdtrace -l
ccwpge0061_41843 (10.158.175.61)
ccwpge0062_55445 (10.158.175.62)
>more /tmp/machines
ccwpge0061:1
ccwpge0062:1
(*)
>mpiexec -machinefile /tmp/machines
-n 2 bin/atest (*)
(*)
L’adressage de la 2eme carte réseau se fait au moment
du lancement des process mpd
mpd lancé dans le PE_start de GE,
donc choix fait via le PE (qsub -pe ...)
>dstat -n -N eth0,eth (*)
768B 718B:1049M 2249k
134B 134B:1049M 2250k
262B 134B:1049M 2249k
346B 366B:1049M 2250k
292B 134B:1049M 2250k
>mpdallexit
>mpdallexit
Table 6: mpi-intel utilisant le 2eme interface réseau (10Gb/s)
0<+>0
MPI-Intel : Memo
Fichier $HOME/.mpd.conf
Nécessaire seulement pour le daemon mpd, son format :
Rappel
MPI +
GE
Annexes
> more ~/.mpd.conf
secretword=xxxx
Fichier devenu inutile avec hydra
Fichier mpd.hosts
Au moins en mode manuel, Il semble indispensable d’avoir un fichier mpd.hosts
(même vide = touch mpd.hosts), car sinon
>mpiexec ...
unable to open (or read) hostsfile mpd.hosts
et malgré ce qui est dit la doc MPI Intel :
The file $PWD/mpd.hosts will be used by default if it is present. If there is no
host file, the mpdboot command will start one MPD daemon on the local
machine.
Version de python
Python 2.6 génere des warning de dépreciation
DeprecationWarning: The popen2 module is deprecated.
Use the subprocess module. /usr/local/intel/mpi/3.0/bin/mpdlib.py:38:
DeprecationWarning: the md5 module is deprecated; use hashlib instead
from md5 import new as md5new
Utiliser python 2.4 ⇒ ok
0<+>0
Rappel
MPI +
GE
Annexes
Autres essais
Disponibilité des tokens AFS sur master et slave,
Verif par l’exemple = ok
Expire à + 48h, conforme à la conf de GE
ccwpge0061 (master) User’s (AFS ID 1815) tokens for [email protected] [Expires Jan
11 13 :29]
ccwpge0062 (slave) User’s (AFS ID 1815) tokens for [email protected] [Expires Jan 11
13 :29]
Disponibilité des $TMDIR sur master et slave,
ccwpge0061 (master) TMPDIR = /scratch/4069706.1.pa_long
Existance réelle ? : oui jusqu’à la fin du script du job
> ls -l /scratch/ drwxr-xr-x 2 bchambon ccin2p3 6 Jan 9 13 :29
4069706.1.pa_long
ccwpge0062 (slave) TMPDIR = /scratch/4069706.1.pa_long
Existance réelle ? : oui tant que la tâche esclave existe
> ls -l /scratch/ drwxr-xr-x 2 bchambon ccin2p3 29 Jan 9 13 :29
4069706.1.pa_long

Slides - indico in2p3

Transcription

Documents pareils

Déroulement - Hotel Bin el Ouidane

Hôtel Bin el Ouidane a vecu une longue expérience en team

OFFRE D`EMPLOI GUIDE-ANIMATEUR

recycle. it`s simple. it`s smart.

Section CGT - Centre Financier de Nantes

MADE IN DESIGN

sciences et gestion de l`environnement

Villa à louer Bin el Ouidane n°1

MPI Mesures Physiques et Informatique

Version PDF du tutoriel