FreeBSD buildkernel és buildworld !vs benchmark

FreeBSD

Dan 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.
Az új HUP szerver is hasonló paraméterekkel rendelkezik (néhol több, néhol kevesebb). Gondoltam, hogy elvégzem én is azokat a méréseket, amiket Dan. Tudom, hogy a két gép összehasonlításából sok következtetést nem lehet levonni, mivel azok nem egyformák, de mégis kíváncsi voltam az eredményekre. Íme:

iXsystems Jupiter RS2350 HP Proliant DL 385
A cikkben szereplő vas Új HUP vas
Dual Opteron 246 @ 2.0 GHz, 8GB RAM, SATA hw RAID Dual dual-core Opteron 275 @ 2.2 GHz, 3 GB RAM, SCSI hw RAID
 
buildkernel 11m 10m25.869s
-j 2 - 5m44.726s
-j 4 - 4m32.874s
-j 8 - 4m47.860s
 
buildworld 56m 57m33.189s
-j 2 36m 30m37.347s
-j 4 36m 18m20.679s
-j 8 36m 18m42.667s
 
-s buildkernel 12m 10m31.037s
-s -j 2 6m 5m44.783s
-s -j 4 7m 4m41.394s
-s -j 8 - 4m54.693s
 
-s buildworld 58m 55m56.784s
-s -j 2 35m 30m42.396
-s -j 4 - 18m18.851s
-s -j 8 - 18m42.161s
 

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.
Az új HUP vasnál is ez figyelhető meg. Mivel négy fizikai prcocesszormag található a gépben (Dual dual-core Opteron), a gép a "-j 4" kapcsoló esetén teljesített a legjobban. A "-j 8" esetén már - ha kicsivel is - de rosszabb eredményeket produkált a gép.
Továbbá megfigyelhetjük, hogy noha a cikk azt állítja, hogy a make "-s" kapcsolója csökkenti a fordítási időt, egyáltalán nem csökkenti, sőt, volt hogy rosszabb időt hozott, mint a nélküle való fordítás.

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.

( bra | 2006. 07. 01., szo – 19:41 )

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.

( whitehawk v | 2006. 07. 01., szo – 22:00 )

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

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.

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.