ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverFreeBSD Project NewsOpenBSD Journal |
FreeBSD buildkernel és buildworld !vs benchmarkDan Langille FreeBSD fejlesztő - többek közt a The FreeBSD Diary és a Freshports oldalak tulajdonosa - nemrég hozzájutott egy dual Opteron 264 szerverhez. A szerver 2U magas, 8GB RAM-mal, és 400 GB-nyi hardveres SATA RAID kontrollerrel vezérelt merevlemezzel rendelkezik. FreeBSD 6.1-RELEASE operációs rendszert telepített a gépre, majd néhány mérést végzett rajta. Többek közt FreeBSD kernel és userland fordítást egy, kettő, négy és nyolc szálon, normál és silent (-s) módban.
Mit lehet a számokból megállapítani? Nem sok mindent, de annyit biztosan, maximum annyi szálon érdemes FreeBSD alatt make-kel fordítani, ahány processzor(mag) van a gépünkben. Jól látható, hogy Dan gépe akkor hozta a legjobb időket, amikor "-j 2" kapcsolót használt. Mivel két fizikai processzor(mag) van a gépében, neki a "-j 2" az ideális. Látható, hogy amikor "-j 4" kapcsolót használt, akkor vagy ugyanolyan, vagy rosszabb eredményt kapott, mint amikor "-j 2"-vel fordított. A fordítások alkalmával FreeBSD 6.1-RELEASE operációs rendszert használtam teljesen szűz (gyári) /etc/make.conf-fal. A kernelfordításokkor GENERIC kernelt használtam.
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekSzavazásNálunk rendszeresen van ISO audit és rendszeradminként ... nekem is van munkám vele. 20% engem nem érint. 16% nálunk nincs minőségirányítási rendszer bevezetve. 31% mi az az ISO audit? 29% Egyéb. Leírom. 4% Összes szavazat: 322
InformációKövess minket!Partnerünk |
Hozzátenném, hogy a buildworld és buildkernel meglehetősen rosszul párhuzamosított, így hiába van egy 16 processzoros géped, amin egy buildworld kb. 3-4 perc lenne, 12-15 alá nem nagyon fog menni.
szomcsi
http://litch.eu/blog
Gentoo make.confhoz azt szokták javasolni, hogy a processzor magok száma plusz egy esetleg 2 legyen a fordítási szálak száma. Lehet, hogy a 2szer annyi szál már nagyon nem optimális, de a +1 esetleg javít a dolgon.
Software is like sex, it's better with a penguin. :D (r)(tm)(c)
"hogy a processzor magok száma plusz egy esetleg 2 legyen a fordítási szálak száma. Lehet, hogy a 2szer annyi szál már nagyon nem optimális, de a +1 esetleg javít a dolgon."
Na nézzük. "-j 4"-gyel 4m32.874s lett a buildkernel. Ennél kellene ezek szerint jobbnak lennie. Négy magom van, akkor legyen +1:
time make -j 5 buildkernel
--------------------------------------------------------------
>>> Kernel build for GENERIC completed on Sun Jul 2 08:43:27 CEST 2006
--------------------------------------------------------------
real 4m38.044s
user 9m53.366s
sys 1m35.209s
Ez rosszabb, mint "-j 4"-gyel. Igaz, csak kicsivel.
Legyen kettővel több:
time make -j 6 buildkernel
--------------------------------------------------------------
>>> Kernel build for GENERIC completed on Sun Jul 2 08:58:50 CEST 2006
--------------------------------------------------------------
real 4m44.951s
user 9m55.133s
sys 1m38.279s
Ez még rosszabb. Nem igazán látom bizonyítottnak, de nem is lenne nagyon logikus. Imho.
--
trey @ gépház
Pedig a Gentoo guide valóban processzorszám+1-et javasol a fordításhoz. Lehetséges, hogy BSD alatt ezt másképpen valósították meg?
--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!
Nyilván más a 4BSD ütemező (az ULE lett volna valami O(1) féle cucc), mint a Linux O(1) ütemezője, de akkor se vágom, hogy mitől lenne gyorsabb a 4 processzor 4 make egy az egyben elképzelésnél a 4 processzor 5 (6) make. Itt szerintem egy mindig vár a processzorra, amíg az ütemező oda nem adja neki. Nekem ennek a kapcsolgatásnak overhead, azaz lassulás szaga van. Valaki?
--
trey @ gépház
Próbáld ki ULE-val, nekem itthon egészen jól ment a tűzfalon 5.4-el, csak 1-2 hetente crashelt el gyanusan. :) Amikor ULE-val csinaltam make -j2-es buildworld-ot itt a kis dualP2-esen, akkor ~30 perccel rövidebb volt ha jól emlékszem. A 30 perc a ~4 órás buildhez képest értendő. :)
A -jX sebessége pedig nagyon sok dologtól függ, de talán diszk/rendszer I/O meghatározó, illetve hogy mennyire tudják a szálak kihajtani a dolgokat. Az Athlon XP-men -j2-vel fényéveket fejlődött a buildworld, de -j3-al már lassult.
"csak 1-2 hetente crashelt el gyanusan"
Na igen, az ULE-nek ez a problémája. Ezért sem lett alapértelmezett CPU ütemező, és ha jól tudom nem is fejlesztik azóta sem.
--
trey @ gépház
Igazából nem tudtam, hogy az ULE a hibás itt, csak igazából rá tudtam gondolni és bejött a tipp. Teszt jelleggel viszont érdemes a buildworld idejére kipróbálni. Valami olyat olvastam, hogy a 7-esben már télleg lesz ULE vagy abból valami, mert a 4bsd má naonrégi megminden, de lehet hogy rosszul emlékszem.
Annyira, hogy CURRENT-en ULE schedulerrel még egy buildworldöt sem mindig él túl az OS.