[Hpc-forum] MPI problemak

2013. Sze. 25., Sze, 07:45:21 CEST

Kedves Fiuk!

Hosszura nyult mar ez a levelezes, nem bongeszem vegig.
Egy dolog azonban gyanusan tartosan megoldatlan, hogy nem mukodik a module 
load.
Csak kibicelek: lehetseges, hogy nincs inicializalva (module use 
/opt/nce/modulfiles ; module load nce/global)?
ÜdvFeri
------------:
Dr. Ferenc BARTHA, tel: 62/54-6821, E-mail: barthaf at sol.cc.u-szeged.hu
SKYPE: ferenc.bartha, WWW: http://www.staff.u-szeged.hu/~barthaf/
SZTE DNT - High Performance Computing Group, 6725 Szeged, Szikra u. 2.
SZTE, Department of Medical Chemistry, 6720 Szeged, Dóm tér 8.
----- Original Message ----- 
From: "Tamas Hegedus" <tamas at hegelab.org>
To: <undisclosed-recipients:>
Cc: <hpc-forum at listserv.niif.hu>
Sent: Tuesday, September 24, 2013 10:52 PM
Subject: Re: [Hpc-forum] MPI problemak

Figyusz,

Igen, elég sok probléma van az információkkal, az információ
minőségével, stb. De azért van ott hasznos információ, s ha nem tudod
kihámozni, akkor meg lehet kérdezni, s amit meg tudnak oldani, megoldják.

Ott van a Te türelmetlenséged is, hogy végig kéne olvasni a
hibaüzenetket. Ha jó emlékszem debrecenben van node-onként 12
processzor. Ha 12 core-t kérsz, s az egy node-on fut, akkor csak a
nodonkent elerheto max memoriát kérheted. Ezt en sem tudom, mennyi, de
szerintem a hibaüzenetben benne volt: 32GB. Azaz ezt szalankenti 8G-val
boven tullepted.

Ha lecsökkentve pl 2Gb-ra sem működik, akkor nem (csak) ez volt a baj.

Itt már kezdődik a nagyon nem hozzáértésem...
Először a modulokat kéne megtalálni. Most úgy néz ki, hogy a modulok
között van olyan, ami szerintem a node-ok közötti optikai kapcsolatot
biztosito eszkoz drivere. Megnezve a niif weboldalt, az lehet a
szituacio, hogy 2x6 core van egy node-on, s azok infiniband-vel
osszekotve. Azaz hiaba egy node-on fog futni a job fizikailag, az a
driver akkor is kell.

Szoval a modulokat kene megtalalni.

A komplikációk ott jönnek ezekkel a tudomanyos programokkal, hogy tele
lehet hibaval. Olyan hibakkal, amit nagyon nehez egy kivulallonak (meg
ha rendszergazda is) debuggolni. Nekem most van egy olyan programom
(hasznalok), ami openmpi-os, mpirun-val elindul 1 node-on, de ha mar
tobb processzort kerek, s tobb node-on kene futnia, akkor izel elindulni...

----
Na jó, biztosan stresszes vagyok, s ez most pótcselekvés

----
Forditanek gyorsan egy sajat openmpi-t.
Na jó, nem. Megvárnám a holnapi napot. Ránézésre, ezt úgy becsülöm, hogy
rendszergazdai oldalról nem túl bonyolult. Ha egy nap alatt nem oldódik
meg, akkor fordítanék egy sajátot.

Valami gumbanc azért lehet a rendszerrel magával, mert ha ssh-zok egy
node-ra, akkor ott a module avail nagyon mást ad ki, nem azt amit
várnék. De lehet, hogy ez nem baj...

Kiváncsi vagyok nagyon a megoldásra, lsz majd írjátok meg, ne csak
magatok között levelezzétek le a végét. Köszönöm!

Üdv,
Tamas

On 09/24/2013 09:52 PM, Tamas Hegedus wrote:
> Kedves Gábor,
>
> Csak most ültem nagy képernyő elé. Továbbra is elképzelhetőnek tartom,
> hogy túl sok memóriát kérsz.
>
> ---
> Rőczei Gábor irta:
> -l h_vmem=1G
> A job csak akkor fog elindulni, ha 1 GByte szabad memória lesz
> valamelyik gépen. Párhuzamos jobok esetén ennek az értéke megszorzódik a
> kért slotok számával.
> Fontos: ha például a párhuzamos jobunk esetén 10 slotot kértünk és
> slotonkét 1 GByte memóriára van szükség akkor h_vmem=1G -t kell megadni,
> nem pedig h_vmem=10G-t!
>
> ---
> Ha ez OK, s megcímezhető mennyiségű memóriát kérsz, akkor lehet, hogy a
> többi hibaüzenet is eltunik.
>
> Ha nem, akkor hasonló hibaüzenethez az alábbi emlékeim merülnek fel:
> * Néha, számomra teljesen érthetetlen okokból, a shared library file-nak
> végrehajthatónak kell lenni ahhoz, hogy be tudjon töltődni; lokalizálni
> kell, hol van fizikailag a file-rendszerben a nem talált file, s
> megnézni, hogy a node-ról elérhető-e. Szerintem egy node-ra be tudsz
> ssh-zni, s utána megnézni, h látszik-e; ha látszik, akkor nézném meg,
> hogy exec-e. Ha nem, akkor lsd következő pont, vagy esetleg a
> rendszergazdák átállítják Neked, ha nem veszélyes, kipróbálásra.
> * ha megvan, látható, s ráadásul még exec is (vagy nem exec, de nem
> állítható exec-re), akkor elfelejtem a rendszerben rendelkezésre álló
> open mpi-t, s fordítok magamnak egy sajátot, mert egyszerűbb és
> gyorsabb, mint debuggolni egy ilyen problémát. (Főleg ha tudósok által
> írt programokat fordítok és használok.) Ekkor fontos, hogy a saját
> openmpi-val inditsd a programot, s az LD_PATH-ba (vagy hasonlóba) is
> belekerüljön a saját openmpi könyvtár (lib).
>
> Ja, felelősséget nem vállalok. Lehet, hogy tele van butasággal, de nekem
> ilyen (hasonló) hibák így megoldódtak eddig.
>
> Üdv,
> tamas
>
> On 09/24/2013 09:20 PM, Tamas Hegedus wrote:
>> Nem lehet, h az a baj, h veletlen 12x8G memoriat akarsz lefoglalni?
>>
>> --
>> Tamas Hegedus
>> tamas at hegelab.org
>>
>> etele molnar <etele.molnar at gmail.com> wrote:
>>
>>> Kedves Gabor
>>>
>>>
>>> Eloszor is koszonom a segitseget es a faradsagot de meg mindig gond van.
>>>
>>>
>>> Igaz most mar van uj gcc 4.7.2 es openmpi 1.6.3 de a problema nem
>>> mult el.
>>> Megjegyzem a /sgi/mpt/2.04 modul alapertelmezett igy csak az elobbi
>>> kettot
>>> adtam hozza a .bashrc-hez.
>>>
>>> Leforditottam ujra a programot, mpicxx vagy mpic++ (gcc)
>>> es futtatni probalom de sajnos most is hibauzenetet kapok
>>>
>>> mpirun-t adtam meg 1 job  8G memoria np=12:
>>>
>>> Warning: Permanently added
>>> '[r1i1n3.ice.debrecen.hpc.niif.hu]:58158,[10.148.0.21]:58158'
>>> (RSA) to the list of known hosts.
>>> Warning: Permanently added
>>> '[r1i0n15.ice.debrecen.hpc.niif.hu]:45141,[10.148.0.17]:45141'
>>> (RSA) to the list of known hosts.
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'openmpi/1.6.3-gcc-4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'openmpi/1.6.3-gcc-4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'gcc/4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'gcc/4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'openmpi/1.6.3-gcc-4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'gcc/4.7.2'
>>> --------------------------------------------------------------------------
>>>
>>> WARNING: It appears that your OpenFabrics subsystem is configured to
>>> only
>>> allow registering part of your physical memory.  This can cause MPI
>>> jobs to
>>> run with erratic performance, hang, and/or crash.
>>>
>>> This may be caused by your OpenFabrics vendor limiting the amount of
>>> physical memory that can be registered.  You should investigate the
>>> relevant Linux kernel module parameters that control how much physical
>>> memory can be registered, and increase them to allow registering all
>>> physical memory on your machine.
>>>
>>> See this Open MPI FAQ item for more information on these Linux kernel
>>> module
>>> parameters:
>>>
>>>     http://www.open-mpi.org/faq/?category=openfabrics#ib-locked-pages
>>>
>>>   Local host:              r1i0n14
>>>   Registerable memory:     32768 MiB
>>>   Total memory:            49143 MiB
>>>
>>> Your MPI job will continue, but may be behave poorly and/or hang.
>>> --------------------------------------------------------------------------
>>>
>>> [r1i0n14:21422] 47 more processes have sent help message
>>> help-mpi-btl-openib.txt / reg mem limit low
>>> [r1i0n14:21422] Set MCA parameter "orte_base_help_aggregate" to 0 to see
>>> all help / error messages
>>>
>>>
>>>
>>> Tovabba ha ugyanezt a programot
>>>
>>> mpirun.sge probalom futtatni (nem lett ujraforditva, maradt a gcc's
>>> forditas) akkor szinten
>>> ugyan ezt a hibaunzenetet kapom csak sokkal hosszabbat es azonnal le
>>> is all
>>> a job...
>>>
>>>
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'openmpi/1.6.3-gcc-4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'gcc/4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'openmpi/1.6.3-gcc-4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'openmpi/1.6.3-gcc-4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'gcc/4.7.2'
>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>> 'gcc/4.7.2'
>>> --------------------------------------------------------------------------
>>>
>>> mpirun was unable to launch the specified application as it could not
>>> find
>>> an executable:
>>>
>>> Executable: r1i0n14.ice.debrecen.hpc.niif.hu
>>> Node: r1i0n14
>>>
>>> while attempting to start process rank 0.
>>> --------------------------------------------------------------------------
>>>
>>>
>>> real    0m1.436s
>>> user    0m0.012s
>>> sys     0m0.016s
>>>
>>> etc...
>>>
>>> ***
>>>
>>> Meg 2 utolso "elmeleti" kerdes
>>> Peldaul; egy program 4 Gb memoriat ker, ha parallel 2 programot
>>> szeretnek
>>> futtatni (./ program & ./ program &)
>>> akkor 2*4 Gb memoriat kerjek vagy csak 4-et ?
>>>> #$ -l h_vmem=8G vagy 4Gb
>>>
>>> Ugyanez a program MPI-s verzioval tegyuk fel 6 slotton
>>> mpirun -np 6 program
>>>
>>> akkor
>>>> #$ -l h_vmem=4G vagy 6*4=24Gb
>>>
>>>
>>> Elore is koszonom
>>> udv
>>> e
>>>
>>>
>>> 2013/9/24 Rőczei Gábor <roczei at niif.hu>
>>>
>>>> Kedves Molnár Etele!
>>>>
>>>>> van egy surgeto problemakor amit nem tudtam megoldani napok ota.
>>>>> Az egyik c++ kodom MPI-t hasznal integralasra, de sajnos nem mindig
>>>> mukodik kellokepp a debreceni gepen.
>>>>>
>>>>> eloszor is az SGE fele mpi-ben nem fordul le mivel nem ismeri fel
>>>>> az MPI
>>>> reszt ?
>>>>> mpi-selector --query -> mpt-2.04
>>>>
>>>> mpi-selector helyett használd inkább a SGI MPT-s modult Debrecenben:
>>>> module load sgi/mpt/2.04
>>>>
>>>> A job scriptben mpirun.sge-t kell majd megadni a futtatáshoz (erre csak
>>>> SGI MPT esetén van szükség, OpenMPI-nál mpirun-t kell használni).
>>>> Példa:
>>>>
>>>> #!/bin/bash
>>>> #$ -N TEST
>>>> #$ -pe mpi 60
>>>>
>>>> mpirun.sge -np $NSLOTS program
>>>>
>>>> Ezeket kell beállítani a fordításkor (akkor ha nem ismeri fel
>>>> automatikusan):
>>>>
>>>> CXXFLAGS=-I/opt/nce/packages/global/sgi/mpt/2.04/include
>>>> CFLAGS=-I/opt/nce/packages/global/sgi/mpt/2.04/include
>>>> FFLAGS=-I/opt/nce/packages/global/sgi/mpt/2.04/include
>>>> LDFLAGS=-L/opt/nce/packages/global/sgi/mpt/2.04/lib -lmpi
>>>>
>>>>> A masik problemam az az, hogy probalom az ujabb gcc/4.6.4 fordito
>>>> csomagot hasznalni es a .bashrc bele is irtam, hogy
>>>>> module load gcc/4.6.4 openmpi/1.6.3-gcc-4.7.2  es ez be is toltodik
>>>> mivel megtalalom a
>>>>> module list parancsal, de mikor a kodot elinditom mindig azt a hibat
>>>> kapom, hogy
>>>>>
>>>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>>> 'gcc/4.6.4'
>>>>> ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
>>>> 'openmpi/1.6.3-gcc-4.7.2'
>>>>
>>>> Debrecenben nem volt telepítve a 4.7.2-es OpenMPI verzió.  Ezt most
>>>> javítottam.
>>>>
>>>> Így tudod betölteni őket:
>>>>
>>>> DEBRECEN[service0] ~ (0)$ module load openmpi/1.6.3-gcc-4.7.2 gcc/4.7.2
>>>> DEBRECEN[service0] ~ (0)$ type gcc
>>>> gcc is /opt/nce/packages/global/gcc/4.7.2/bin/gcc
>>>> DEBRECEN[service0] ~ (0)$ type mpirun
>>>> mpirun is /opt/nce/packages/global/openmpi/1.6.3-gcc-4.7.2/bin/mpirun
>>>> DEBRECEN[service0] ~ (0)$
>>>>
>>>>> erdekes az is, hogy az mpicxx.openmpi-t nem ismeri fel a
>>>> szuperszamitogep !
>>>>
>>>> OpenMPI esetén mpirun-t használj. Úgy van fordítva az OpenMPI, hogy
>>>> képes
>>>> értelmezni az SGE által definiált PE_HOSTFILE-os környezeti változót:
>>>>
>>>> DEBRECEN[service0] mpi (0)$ ompi_info -all | grep gridengine
>>>>                   MCA ras: gridengine (MCA v2.0, API v2.0, Component
>>>> v1.6.3)
>>>>                   MCA ras: parameter "ras_gridengine_debug" (current
>>>> value:
>>>> <0>, data source: default value)
>>>>                            Enable debugging output for the
>>>> gridengine ras
>>>> component
>>>>                   MCA ras: parameter "ras_gridengine_priority" (current
>>>> value: <100>, data source: default value)
>>>>                            Priority of the gridengine ras component
>>>>                   MCA ras: parameter "ras_gridengine_verbose" (current
>>>> value: <0>, data source: default value)
>>>>                            Enable verbose output for the gridengine ras
>>>> component
>>>>                   MCA ras: parameter "ras_gridengine_show_jobid"
>>>> (current
>>>> value: <0>, data source: default value)
>>>> DEBRECEN[service0] mpi (0)$
>>>>
>>>> Megjegyzés: OpenMPI helyett SGI MPT-t használj ha van rá
>>>> lehetőséged, mert
>>>> ez sokkal jobban ki tudja használni az SGI-s architektúrát Debrecenben.
>>>>
>>>> Ezt cseréltem: mpiexec --> mpirun
>>>>
>>>>> mi van akkor ha egyszerre 2 mpis programot futtatok pl,
>>>>>
>>>>> #!/bin/sh
>>>>> #$ -N test2
>>>>> #$ -l h_vmem=4G
>>>>> #$ -l h_rt=23:59:59
>>>>> #$ -pe mpi 24
>>>>> #$ -q parallel.q
>>>>>
>>>>> time mpirun -np 12 ./kod $writedir01/ > kod.out1 &
>>>>> time mpirun -np 12 ./kod $writedir11/ > kod.out2 &
>>>>> wait
>>>>>
>>>>> ez magatol erthetodo ? 24 thread 2 reszre osztva ? es "&" parhuzamosan
>>>> futtnak
>>>>
>>>> Igen, ez így fog történni.
>>>>
>>>> Ez pedig egymás után fogja lefuttatni:
>>>>
>>>>> time mpirun -np 24 ./kod $writedir01/ > kod.out1 ;
>>>>> time mpirun -np 24 ./kod $writedir11/ > kod.out2 ;
>>>>
>>>> Üdvözlettel,
>>>>
>>>>      Rőczei Gábor
>>>
>>> _______________________________________________
>>> Hpc-forum mailing list
>>> Hpc-forum at listserv.niif.hu
>>> https://listserv.niif.hu/mailman/listinfo/hpc-forum
>> _______________________________________________
>> Hpc-forum mailing list
>> Hpc-forum at listserv.niif.hu
>> https://listserv.niif.hu/mailman/listinfo/hpc-forum
>>
>
>

-- 
Tamas Hegedus, PhD
Senior Research Fellow
MTA-SE Molecular Biophysics Research Group
Hungarian Academy of Sciences  | phone: (36) 1-459 1500/60233
Semmelweis University          | fax:   (36) 1-266 6656
Tuzolto utca 37-47             | mailto:tamas at hegelab.org
Budapest, 1094, Hungary        | http://www.hegelab.org

_______________________________________________
Hpc-forum mailing list
Hpc-forum at listserv.niif.hu
https://listserv.niif.hu/mailman/listinfo/hpc-forum 