[Hpc-forum] SLURM utemezo es memoria OMP joboknal

[Balazs Nagy]

Azert nem, mert az altalam leggyakrabban hasznalt ab initio programok 
eseten (Cfour, Molpro, G09) nem linearis a skalazodas az OpenMP szalak 
szamaval, inkabb maximum gorbe szerint alakul. Gondolom, a job komoly 
I/O igenye miatt. Tobb gepen, tobb tesztet is futtattam, melyek szerint 
a szamitasi szinttol (SCF, MP2, CCSD, (T), stb.) fuggoen van egy 
optimalis OMP_NUM_THREADS ertek, amin erdemes futtatni. Ez a fenti 
programok eseten 2-6. Ennel tobb szalat hiaba adok meg, a job nem lesz 
gyorsabb, a load nem lesz maximalis, sot, egyes esetekben, ahol esetleg 
tobb TB adat I/O-zik, az egesz futas lassabb lesz.
A job-jaim legtobbszor ab initio szamitasok magas korrelacios szinteken: 
CCSD(T), T, (Q), Q, ... Ezek 90%-ban napokig, de inkabb hetekig, vagy 
akar egy honapig is futnak, es legtobbszor nem ujraindithatok a 
leallasuk utan, az elejuktol kell oket ujrainditani. A pecsi gep gyakori 
meghibasodasa miatt ott ilyen job-ot nem nagyon tudok (merek) elinditani.

Egyelore tesztelem a cpu+memoria szamlazast es esetleg kerunk meg 
eroforrast. Ezzel viszont eleg sok CPU hasznalaton kivul, uresjaraton 
fog mukodni, ami eppen az utemezo cserejenek koncepcioja ellen fog szolni.

Udv.,
Balazs


On 05/23/2014 01:59 PM, Hornos Tamas wrote:
> On 5/23/14 1:07 PM, Balazs Nagy wrote:
>> Kedves Tamas!
>>
>> Ertem a szamlazasi koncepciot, de nem tartom fairnek. Egyreszt a 2600
>> MB/core memoria manapsag mar egy alap laptopban is elerheto. A
>> szamlazasi rendszer ebben a formaban kizarolag a CPU igenyes
>> feladatokat tamogatja, ami rendben is lenne, viszont a nagy
>> memoriaigeny kiszolgalasanak CPU szamlahoz torteno hozzairasa
>> szerintem nem szerencses. Ezzel - a tulszamlazasi probleman tul -
>> feleslegesen foglalom  a CPU-kat a job-omhoz, amiket nem feltetlenul
>> kellene. Rengeteg olyan job van, aminek eleg a default 1000 MB/core
>> memoria, vagy akar meg ennel is kevesebb, igy a keves szalon futo, de
>> nagyobb memoriat igenylo job-ok melle lehetne utemezni az elobbieket.
>> Az elozo utemezo (-l h_vmem) ezt tapasztalataim szerint jol kezelte,
>> az uj ezek szerint erre nem kepes? Azaz a nagy memoriat igenylo job-ok
>> a memoria miatt 2X, 3X, 4X, ... kerulnek felszamlazasra memoria
>> igenytol fuggoen? Mindenkeppen szeretnenk, ha egy, a regi utemezohoz
>> hasonlo memoriafoglalasi rendszert vezetnetek be a SLURM utemezot
>> hasznalo gepeken.
>>
>> Koszonettel,
>> Balazs
>>
> A számlázásra a fair és tervezhető elosztás miatt van szükség. Nem az a
> probléma, ha valaki sok időt kér, hanem ha nem használja el.
>
> A memória / core arány valóban nem nagy, HPC viszonylatban viszont átlag
> fölötti!. Ezek a gépek már 3 évesek, és gondolom azt sem kell említenem,
> hogy itt enterprise grade ECC memóriákról van szó. Laptoppal
> összehasonlítani a HPC node-okat nem igazán érdemes. Nagymemóriás OpenMP
> jobokat a pécsi gépen tudunk kiszolgálni. Az előző ütemezővel több más
> probléma is volt. A jelenlegi helyzet egy világos, átlátható, tervezhető
> rendszer.
>
> A "felszámlázással" nincs probléma, több CPU időt kell kérni. Az ilyen
> jobokat ún. bigmem sorokban (bigmem node-okon) szokták futtatni, ahol a
> számlázási szorzó >1. A memória szorzó lényege az, hogy a memória is
> foglalható erőforrás. Ez a fajta CPU / memória elszámolás az összes
> nagyobb HPC központra jellemző.
>
> Én azt szeretném megkérdezni, hogy miért nem tudod kihasználni az összes
> OpenMP szálat?
>
> Üdv
>


-- 
Balazs, NAGY
Research Assistant
MTA-BME "Lendület" Quantum Chemistry Research Group
Department of Physical Chemistry and Materials Science
Budapest University of Technology and Economics
P.O. Box 91
H-1521 Budapest
Hungary
Phone: +36-1/463-1632