Produkˇcn´ı u´lohy ALICE na farmˇe Goli´aˇs Dagmar Adamov´a, Jiˇr´ı Chudoba 7.1.2007
1
Produkce ALICE
V r´amci Physics Data Challenge 2006 (PDC’06), mas´ıvn´ıho testu v´ ypoˇcetn´ıho modelu projektu ALICE v distribuovan´em prostˇred´ı, byly na farmˇe Goli´aˇs zpracov´av´any produkˇcn´ı u ´ lohy nepˇretrˇzitˇe v obdob´ı ˇcerven - prosinec 2006. Jednalo se o Monte Carlo simulace pˇr´ıpad˚ u sr´aˇzek p+p a Pb+Pb. Fungov´an´ı PDC’06 bylo zajiˇst’ov´ano kombinac´ı prvk˚ u middleware projekt˚ u LCG a ALICE Grid (AliEn). Lok´alnˇe pouˇzit´e middleware komponenty byly: LCG Computing Element, PBSPro server, Worker Node (WN), LCG File Catalogue LFC a VO-box s instalovan´ ym User Interface. AliEn servery v CERN zajiˇst’ovaly centr´aln´ı sluˇzby, tj. AliEn catalogue, job submission/control, task queue a monitoring. Na farmˇe Goli´aˇs byl AliEn nainstalov´an na ALICE VObox do adres´aˇre sd´ılen´eho s WNs. Popis funkc´ı middleware komponent lze nal´ezt v [1, 2].
1.1
Pouˇ zit´ y hardware
V´ ypoˇcetn´ı uzly farmy Goli´aˇs m˚ uˇzeme rozdˇelit do nˇekolika skupin podle jejich hardware: HP LP1000r, 2x Pentium III 1.13GHz, 1 GB RAM, 18 GB SCSI hard disk, 2 GB swap HP ProLiant DL140, 2x XEON 3.06 GHz, 2 GB RAM, 40 GB ATA hard disk, 4 GB swap, HyperThreading vypnut HTof f HP ProLiant DL140, 2x XEON 3.06 GHz, 4 GB RAM, 40 GB ATA hard disk, 4 GB swap, HyperThreading zapnut HTon HP Blade BL35p, 2x Opteron 275, 2.2 GHz, dual core, 4 GB RAM, 40GB ATA disk, 4 GB swap HP Blade BL35p, 2x Opteron 280, 2.4 GHz, dual core, 8 GB RAM, 72GB SAS disk, 8 GB swap
1
Farma pouˇz´ıv´a lok´aln´ı d´avkov´ y syst´em PBSPro [3], pro produkˇcn´ı gridov´e u ´ lohy alice je vyhrazena fronta lcgaliceprod. Vzhledem k vysok´ ym pamˇetov´ ym n´arok˚ um simulaˇcn´ıch u ´ loh ALICE byl nastaven scheduler tak, aby se u ´ lohy nespouˇstˇely na stroj´ıch s pouze 1 GB pamˇeti.
2
Porovn´ an´ı pomoc´ı ALICE u ´ loh
ALICE pro distribuci produkˇcn´ıch u ´ loh vyuˇz´ıv´a mechanismus, kter´ y pos´ıl´a pilotn´ı u ´ lohy. To jsou kr´atk´e obecn´e u ´ lohy, kter´e po spuˇstˇen´ı na pracovn´ım uzlu (WN) zkontroluj´ı podm´ınky pro bˇeh u ´ lohy a pak si na centr´aln´ım serveru vyˇza´daj´ı konkr´etn´ı zad´an´ı u ´ lohy. Mezi tˇemito u ´ lohami mohou b´ yt produkˇcn´ı u ´ lohy i u ´ lohy od uˇzivatel˚ u, priority jsou urˇcov´any na centr´aln´ım serveru. Vzhledem k tomu, ˇze uˇzivatelsk´ ych u ´ loh bylo v pomˇeru k produkci velmi m´alo, m˚ uˇzeme pˇredpokl´adat, ˇze v kratˇs´ıch ˇcasov´ ych intervalech jsou t´emˇeˇr vˇsechny u ´ lohy stejn´e z hlediska v´ ypoˇcetn´ı n´aroˇcnosti. Pˇresn´a detailn´ı anal´ yza chov´an´ı u ´ loh by vyˇzadovala zkoum´an´ı jejich log soubor˚ u a ovˇeˇren´ı, zda byl v´ ysledek validov´an. Tyto log soubory jsou v nˇekter´ ych pˇr´ıpadech jen obt´ıˇznˇe dosaˇziteln´e a pro mnoho u ´ loh, kter´e neskonˇcily u ´ spˇeˇsnˇe, ani neexistuj´ı. Proto jsme pro porovn´an´ı v´ ykonnosti r˚ uzn´ ych typ˚ u WN v ALICE produkˇcn´ıch u ´ loh´ach pouˇzili jednoduˇsˇs´ı zp˚ usob pomoc´ı anal´ yzy log soubor˚ u d´avkov´eho syst´emu PBSPro. Porovnali jsme poˇcet a d´elku u ´ loh na jednotliv´ ych skupin´ach WN. Typick´a simulaˇcn´ı u ´ loha potˇrebuje i na nejrychlejˇs´ıch procesorech nˇekolik hodin ´ v´ ypoˇcetn´ıho ˇcasu (CPUTime). Ulohy, kter´e spotˇrebovaly m´enˇe neˇz 1000 s v´ ypoˇcetn´ıho ˇcasu, nemohly skonˇcit u ´ spˇeˇsnˇe, vˇsechny takov´e u ´ lohy povaˇzujeme za chybn´e. Nˇekter´e u ´ lohy jsou ztraceny i po vyuˇzit´ı mnoha hodin procesorov´eho ˇcasu (CPUTime), takov´e vˇsak v naˇsem zjednoduˇsen´em pˇr´ıstupu nedok´aˇzeme odliˇsit od validovan´ ych u ´ loh. Dalˇs´ım zdrojem neefektivn´ıho pouˇzit´ı zdroj˚ u jsou u ´ lohy, kter´e neberou CPUTime, ale z˚ ust´avaj´ı na WN a blokuj´ı spuˇstˇen´ı dalˇs´ıch u ´ loh. Tyto u ´ lohy maj´ı velk´ y rozd´ıl mezi CPUTime a celkov´ ym spotˇrebovan´ ym ˇcasem (WallTime). Porovn´an´ı jsme prov´adˇeli pro 3 ˇcasov´e u ´ seky, kaˇzd´ y o d´elce 9 dn´ı. Z tabulky 1 je vidˇet, ˇze naprost´a vˇetˇsina u ´ loh na uzlech s HTon neprobˇehla spr´avnˇe, CPUTime byl velmi kr´atk´ y. Aˇckoliv dlouh´e u ´ lohy na uzlech s HT on a s HTof f maj´ı stejn´ y pr˚ umˇern´ y ˇcas, velik´ y rozptyl pro u ´ lohy na uzlech s HTon naznaˇcuje, ˇze u ´ lohy nekonˇcily u ´ spˇeˇsnˇe. Celkov´ y ˇcas promarnˇen´ y kr´atk´ ymi u ´ lohami na tˇechto uzlech je ekvivalentn´ı neust´al´emu pouˇzit´ı t´emˇeˇr 9 procesor˚ u (79/9). Mal´ y rozptyl celkov´eho ˇcasu pro u ´ lohy na Xeonech s HTof f a Opteronech umoˇzn ˇ uje urˇcit relativn´ı v´ ykonnost tˇechto procesor˚ u pro ALICE simulace 2
Xeon HTon
Xeon HTof f
Opteron 275
371 164 8.2 ± 7.2 10.6 ± 8.5
862 321 8.2 ± 0.8 9.0 ± 1.2
721 202 6.0 ± 0.6 6.7 ± 0.8
8810 79
483 4
225 2
dlouh´e poˇcet WallTime - souˇcet (dny) CPUTime - pr˚ umˇer (h) WallTime - pr˚ umˇer (h) kratk´e poˇcet WallTime - souˇcet (dny)
Tabulka 1: V´ ysledky pro obdob´ı 10.7.2006 - 18.7.2006 cpu_h
CPU Time - HT on
Entries Mean RMS
45
Entries Mean RMS
300
40
862
8.18 1.343
250
35 30
200
25
150
20
100
15 10
50
5 0 0
cpu_h2
CPU Time - HT off
371
8.199 7.206
5
10
15
20
0 0
25 30 35 CPU Time [hours]
5
10
15
20
25 30 35 CPU Time [hours]
Obr´azek 1: Rozdˇelen´ı CPU ˇcasu pro u ´ lohy na uzlech se zapnut´ ym HTon a vypnut´ ym HTof f 1.34. Velmi podobn´ y pomˇer (1.36) vych´az´ı i pro CPU ˇcas. Je tedy moˇzno ˇr´ıci, ˇze jeden uzel Blade BL35p se 2 dvouj´adrov´ ymi procesory a 4 GB RAM byl ekvivalentn´ı 2.7 (2 kr´at 1.35) uzl˚ um DL140, kaˇzd´ y se 2 procesory a 2 GB RAM. Ve druh´em sledovan´em obdob´ı byl PBS scheduler nastaven tak, ˇze u ´ lohy ve frontˇe lcgaliceprod vyˇzadovaly alespoˇ n 1100 MB voln´e pamˇeti: set queue lcgaliceprod resources default.mem = 1100mb. Zmˇena byla provedena 20.7.2006. Typicky to znamen´a, ˇze na jednom uzlu s HTon nemohou najednou bˇeˇzet 4 u ´ lohy alice. Je jasn´ y pozitvn´ı efekt na v´ ysledky - poˇcet kr´atk´ ych u ´ loh se sn´ıˇzil a rozptyl ˇcasu se zmenˇsil. Nezjistili jsme, proˇc se zv´ yˇsil poˇcet kr´atk´ ych u ´ loh na uzlech s HTof f . Vˇetˇs´ı rozptyl u pr˚ umˇern´ ych ˇcas˚ u na uzlech s HTof f a s Opterony je zp˚ usoben dlouh´ ymi 3
konci rozdˇelen´ı ˇcas˚ u smˇerem k vyˇsˇs´ım hodnot´am. M˚ uˇzeme se dohadovat, zda je to zp˚ usobeno souˇcasn´ ym bˇehem jin´ ych neˇz ALICE u ´ loh na stejn´ ych uzlech. Pokud u ´ lohy jin´ ych uˇzivatel˚ u bˇeˇzely na stejn´em WN, mohly ovlivnit v´ ypoˇcetn´ı ˇcasy pro u ´ lohy ALICE, i kdyˇz byly spouˇstˇeny na samostatn´ ych procesorech. Pomˇer pr˚ umˇern´eho spotˇrebovan´eho ˇcasu pro u ´ lohy na uzlech s HTon a s HTof f je 10.3/8.6=1.2. Pokud bychom pˇredpokl´adali vˇzdy 3 u ´ lohy na uzlu s HTon a 2 u ´ lohy na uzlu s HTof f , ukazuje se zapnut´ı HT jako uˇziteˇcn´e. 6 u ´ loh se na 1 uzlu s HTon v pr˚ umˇeru spoˇcte za 20.6 hodiny a na uzlu s HTof f za 25.8 h, vyuˇzit´ı HT pˇrin´aˇs´ı zrychlen´ı o 25%. V´ ykonnostn´ı pomˇer mezi procesory Opteron a Xeon (HTof f ) se sn´ıˇzil z 1.35 na 1.2, d˚ uvod nen´ı zn´am. Pomˇer v´ ykon˚ u mezi CPU Opteron a Xeon (HTof f ) se v prosinci zv´ yˇsil na hodnotu 1.44. V z´aˇr´ı se pro u ´ lohy pouˇz´ıvaly stroje BL35p (golias101 aˇz golias110), na kter´e byly u ´ lohy pos´ıl´any vˇzdy, kdyˇz se uvolnilo alespoˇ n jedno j´adro. Na stejn´ ych stroj´ıch mohly bˇeˇzet u ´ lohy i z jin´ ych projekt˚ u, nastaven´ı scheduleru by mˇelo zajistit vˇzdy nejv´ıce jednu u ´ lohu na jedno j´adro. V prosinci se pouˇz´ıval pouze jeden stroj BL35p se 2 procesory Opteron 280 (dohromady 4 j´adra), kter´ y byl vyhrazen pouze pro ALICE u ´ lohy. Procesory Opteron 280 by mˇeli b´ yt d´ıky vyˇsˇs´ı frekvenci (2.4 GHz) o t´emˇeˇr 10 % rychlejˇs´ı neˇz procesory Opteron 275 s frekvenc´ı 2.2 GHz. Stroj byl osazen 8 GB RAM, ale j´adro linuxu (2.4.21-37.EL.cernsmp, stejn´e jako na golias101 - golias110) dok´azalo pouˇz´ıvat pouze 4 GB. Pˇri n´ahodn´ ych kontrol´ach bylo vyuˇzit´ı swap v ˇra´dech stovek MB, nevyuˇzit´ı cel´e dostupn´e pamˇeti by nemˇelo pˇr´ıliˇs ovlivˇ novat v´ ypoˇcetn´ı ˇcas. Stroje s HTon nebyly vyuˇz´ıv´any v˚ ubec kv˚ uli pot´ıˇz´ım pˇri nastavov´an´ı fair share syst´emu v scheduleru PBS. 11 WN s HTof f bylo exkluzivnˇe vyhrazeno
dlouh´e poˇcet WallTime - souˇcet (dny) CPUTime - pr˚ umˇer (h) WallTime - pr˚ umˇer (h) kratk´e poˇcet WallTime - souˇcet (dny)
Xeon HTon
Xeon HTof f
Opteron 275
586 252 8.4 ± 3.4 10.3 ± 3.8
394 142 6.0 ± 2.2 8.6 ± 3.7
493 161 5.0 ± 1.2 7.8 ± 5.0
477 10
761 12
802 14
Tabulka 2: V´ ysledky pro obdob´ı 10.9.2006 - 18.9.2006
4
Xeon HTon
Xeon HTof f
Opteron 280
0 0 0 0
764 170 4.9 ± 1.5 5.3 ± 1.7
193 30 3.4 ± 1.2 3.7 ± 1.4
0 0
1536 20
350 4
dlouh´e poˇcet WallTime - souˇcet (dny) CPUTime - pr˚ umˇer (h) WallTime - pr˚ umˇer (h) kratk´e poˇcet WallTime - souˇcet (dny)
Tabulka 3: V´ ysledky pro obdob´ı 10.12.2006 - 18.12.2006
pro ALICE u ´ lohy, ˇza´dn´e jin´e u ´ lohy se na tˇechto stroj´ıch nespouˇstˇely. Zv´ yˇsen´ı poˇctu kr´atk´ ych u ´ loh na WN s HTof f oproti hodnot´am ve sledovan´em u ´ seku v z´aˇr´ı pˇribliˇznˇe odpov´ıd´a zv´ yˇsen´ı poˇctu dlouh´ ych u ´ loh (764/394 = 1.9 vs 1536/761 = 2.0). Je nasnadˇe z´avˇer, ˇze poˇcet kr´atk´ ych u ´ loh nen´ı negativnˇe ovlivnˇen sd´ılen´ım WN s u ´ lohami jin´ ych experiment˚ u.
3
Z´ avˇ er
Sledovali jsme poˇcty a pr˚ umˇern´e ˇcasy ALICE u ´ loh ve 3 r˚ uzn´ ych obdob´ıch. Uk´azali jsme nezbytnost nastaven´ı poˇzadavku na pamˇet’ pro u ´ lohy spouˇstˇen´e na WN s HTon . Spouˇstˇen´ı 3 u ´ loh na 1 WN s HTon vede k urychlen´ı v´ ypoˇct˚ u o 25% v pomˇeru k WN s HTof f . Jedno j´adro procesoru Opteron 275 2.2 GHz bylo pro ALICE v´ ypoˇcty o 20% aˇz 35% rychlejˇs´ı neˇz 1 procesor Xeon 3.06 GHz.
Reference [1] AliEn homepage: http://alien.cern.ch [2] LCG and gLite middleware: http://glite.web.cern.ch/glite/packages/ [3] Altair PBSPro: http://www.altair.com/software/pbspro.htm
5
