[Hpc-forum] debreceni hpc

[Rőczei Gábor]

Szia Miklós,

On 2012.09.11., at 15:49, Miklos Emri wrote:

> Szia Gábor!
> 
> Köszi az információt: a serial/parallel sorokról ezt nem tudtuk (gondolom elkerülte a figyelmünket valamelyik doksiban).
> 
> A döntésetek, hogy a párhuzamos jobokat részesítitek előnyben érthető, ha a job-ok nagy része nem adatpárhuzamosságon alapul. Ha azonban a jobok jelentős része ilyen, akkor teljesen mindegy, hogy az sge vagy egy belső kód darabolja az adatokat.

Tévedés. Az SGE nem darabol semmit sem. Ütemezi a jobok elindítását. Akkor indítja el őket, ha van szabad CPU.

> Az esetemben  nem gond az átírás, mert saját programról van szó, de aki más szoftverét használja (pl. gate, fsl) az nem tudja ezt megoldani és marad a több napos várakozás.

Egy kérdés: lefutottak már a jobjaid? Ezt a levelet tegnap írtad. Az SGE queue-ban nem látok "emri" felhasználóhoz tartozó jobot Debrecenben.

> 
> Arra nem gondoltatok, hogy az erőforrásokat dinamikusan osszátok meg? P.l. 15 percenként a szabad gépeket ahhoz a sorhoz rendelitek ami a terheltebb?

A jobok elindításakor/ütemezésekor több szempontot is figyelembe vesz az SGE (ezt mind automatikusan végzi). Például azt is hogy egy adott job mióta áll a várakozó sorban. Ha régebben tartózkodik ott akkor nagyobb prioritása lesz egy idő után.

Példa:

qstat -u \* -ext

A 2. oszlopot (prior) figyeld meg. Ezt időnként frissíti az SGE.

> Esetleg nincs megoldás (sge konfig) arra. hogy a hosszan futó job-okat egy időre leültetitek, hogy  a rövidebb futásidejű job-ok is kapjanak processzort (ezzel a nagy számolásigényű jobok futási ideje kisebb arányban nőne ugyan, de a rövid számolást igénylő job-ok megkapnák azt a számolsái kapocitást amit igényelnek).

Folyamatosan figyeljük a jobok alakulását és próbáljuk hangolni az SGE ütemezési stratégiáját. Legutóbb például ezért lett bevezetve a serial.q/parallel.q páros.  Itt láthatjátok, hogy az elmúlt egy hónapban melyek voltak a legaktívabb HPC projektek Debrecenben:

https://dl.dropbox.com/u/2545231/HPC/debrecen-hpc-usage-last-30-days.png

Ezzel arra akarok kilyukadni, hogy nagyon sok HPC felhasználó igényeit kell kielégítenünk. Tökéletes sose lesz, maximum egy picit jobb. 

> Elnézést a  "kötekedésért", de lassan ott tartunk, hogy fejben hamarabb megoldom a problémát mint ahogy job-jaim futásra kerülnek.

Hidd el, hogy mindent megteszünk azért, hogy minél jobb legyen a HPC szolgáltatásunk.

Gábor

> 
> On 09/10/2012 08:51 AM, Rőczei Gábor wrote:
>> Szia Miklós,
>> 
>> A jobjaid serial jobok, melyek nem használják ki a több CPU-s környezetet. Ebből kifolyólag a serial.q-ban fognak "elindulni". Debrecenben jelenleg 432 ilyen jobot lehet elindítani összesen.
>> 
>> Így áll most a várakozó sor (a serial.q esetén nincs szabad hely):
>> 
>> roczei at service0:~> qstat -g c
>> CLUSTER QUEUE                   CQLOAD   USED    RES  AVAIL  TOTAL aoACDS  cdsuE
>> --------------------------------------------------------------------------------
>> parallel.q                        0.47    492      0    599   1092     12      0
>> serial.q                          0.98    432      0      0    432      0      0
>> test.q                            0.09      0      0     12     12      0      0
>> roczei at service0:~>
>> 
>> Előbb-utóbb el fog indulni. Várnod kell türelmesen.
>> 
>> Gábor
>> 
>> Ui.: Csak megjegyzésként jegyzem meg, hogy az ilyen serial jobokat nem szuperszámítógépen kellene futtatni, hanem grides környezetben. Magyarországon a Hungrid pont ezt a célt szolgálja. Bővebb információ: http://www.lcg.kfki.hu/ A szuperszámítógépeken mi elsősorban a párhuzamos jobokat preferáljuk és azok számára biztosítunk több CPU erőforrást.
>> 
>> On 2012.09.10., at 7:32, Miklos Emri wrote:
>> 
>>> Sziasztok!
>>> 
>>> Normálisnak tekinthető, hogy egy hpc-n (pl. a debreceni) egy job 14 óra után is wait állapotban van?
>>> 
>>> Üdv
>>> Miklós
>>> 
>>> _______________________________________________
>>> Hpc-forum mailing list
>>> Hpc-forum at listserv.niif.hu
>>> https://listserv.niif.hu/mailman/listinfo/hpc-forum
>