[Hpc-forum] Minden gép - Re: Budapesti gép

[Gábor Rőczei]

Kedves Etele!

2014.01.28. dátummal, 11:42 időpontban etele molnar <etele.molnar at gmail.com> írta:

> Emberek!
> 
> 
> hasonlo a helyezet a debreceni gepen is, valakik "exlusive resorce"-t kertek tobb nodra. Ilyen volt a minap szegeden is.
> Ezen valtoztatni kellene mert ha minden molnar a sajat malmara hajtja a vizet ;-) , akkor egyeseknek jut masoknak nem.
> 
> Itt szamszeruleg vegyuk a dolgokat: mostanaban peldaul van tobb 100-jobom ami openmp -t es mpi-t hasznal,
> a jobok altagban 2 - 24 ora alatt futtnak le mondjuk 6, 9  vagy 12 cpu-magon.
> Termeszetesen ha sajat rendeklezesemre all(na) 200-300 cpu akkor 3-4 nap alatt befejezem a munkat es johet a tanc,
> de mivel eleg gyakran szaturaltak a gepek igy folyamatosan kell lesnem, hogy mikor kuldjek be ujabb jobokat,
> azert hogy a queue-ben se legyen tobb 100-job, de igy pontosan 2-3 hetig tart a melo (olyan jo magyarosan).
> 
> A problema szerintem ott van, hogy a jelenlegi FIFO rendszer nem elegge "demokratikus", es figyelmen kivul hagyja azt, hogy vannak
> jobok melyek par-orasak de olyanok is, hogy hetek kellenek (mindket esetben azonos szamu cpu hasznalataval)
> Ez persze nem baj, sot ezt a kiindulopont, vagyis mindket queue-t, a serial.q es parallel.q-t fel kellene osztani rovid es hosszabb
> futasi idot engedelyezo egysegekre (pl sparallel.q es lparralel.q a short es long-bol), peldaul  2/3 - 1/3 aranyban, vagy ami szukseges a felhasznaloknak.
> Ezeket az aranyokat a rendszergazdak az eddigi logokbol barmikor meg tudjak mondani de ha megsem akkor mindig lehet parasztosan < 24h
> es > 24h osztani, es majd finomhangolni a node-ok szamat is.
> 
> Ha ezt a felhasznalok tobbsege is esszerunek talalja akkor megerne egy probat peldaul a kovetkezo karbantartas ideje alatt el is lehet(ne) vegezni.

Ez már részben meg van csinálva. A végleges megoldás az lesz, hogy mindenhol SLURM ütemezőt fogunk bevezetni. Ebben ugyanis sokkal kifinomultabb megoldások léteznek mint az SGE-ben.

Jelenleg Szegeden a szegedi projektek, pécsen a pécsi projektek, debrecenben a debreceni projektek kapnak nagyobb prioritást az SGE várakozó sorokban.  A qstat kimenetében a jobhoz tartozó prioritás érték a “prior” oszlopban található:

job-ID  prior   name       user         state submit/start at     queue                          slots ja-task-ID

Ennek elsősorban addig van szerepe amíg a job el nem indul.

Funkcionális  ütemezés van beállítva nálunk, ami egyszerűen fogalmazva annyit jelent hogy ticket-ek osztunk szét a felhasználóknak és  a projekteknek. A döntéseket elsődlegesen a projektek szintjén hozzá meg az SGE. Itt van egy rövid magyarázat a funkcionális ütemezésről:

http://www.gridengine.info/2005/09/30/pretty-pictures-explain-functional-vs-sharetree-scheduling/

Azt is figyelembe veszi, hogy az egyes felhasználóknak éppen mennyi futó jobja van és ennek függvényében fog elfogyni a saját ticket-jük. Továbbá az SGE azt is vizsgálja, hogy egy job milyen régóta van a várakozó sorban és ha régebben van mint a többi akkor nagyobb lesz a prioritása.

Például van két projektünk: A illetve B és most Debrecenben vagyunk

Az A projekt jobjai nagyobb prioritást fognak kapni Debrecenben amikor a hozzá tartozó qw (el nem indult) állapotú jobokat ki fogja választani az ütemező, mint a B projekt jobjai. Oka: a B projekt szegedi és ezért ők Debrecenben nem kapnak nagyobb prioritást.

DEBRECEN[service0] ~ (0)$ getent group B
B:*:2000:judit
DEBRECEN[service0] ~ (0)$  getent group A
A:*:3000:andras,janos,tamas,zoli
DEBRECEN[service0] ~ (0)$ qconf -sprj A
name A
oticket 0
fshare 1000
acl A
xacl NONE
DEBRECEN[service0] ~ (0)$ qconf -sprj B
name B
oticket 0
fshare 100
acl B
xacl NONE
DEBRECEN[service0] ~ (0)$ 

A Judit féle jobok a B projekthez fognak tartozni és annak csak 100 a fshare értéke. Andrásék jobjai pedig az A projekthez fognak tartozni, aminek viszont 1000 az fshare értéke, mivel debreceni projektről van szó. Ezért Andrásék jobjai hamarabb fognak elindulni, mert 1000 nagyobb mint a 100. Így most már láthatjátok, hogy az SGE-ben hogyan van ez beállítva. Remélem, hogy ez segít abban, hogy jobban megértsétek az ütemezés jelenlegi működését.

Ha valami nem világos akkor írjatok nyugodtan. Annyi lenne a kérésem, hogy maradjon CC-ben a hpc-forum lista.

Gábor