Quickbench: Linux és Solaris a Sun T2000-es gépén

Miért quickbench? Azért, mert nyomatékosítani szeretném, hogy ezeknek a teszteknek semmi közük a valósághoz, csupán gyors (szintetikus) benchmarkok, mindenféle előzetes tuningolás, és az eredmények részletes értékelése, azok tesztekbe való visszacsatolása nélkül.

Na de nézzük, mink is van: a nálunk járt Sun T2000-es 8 GB memóriát, két 72 GB-os 2,5"-es SAS diszket és egy darab 8 magos, 1 GHz-es UltraSPARC T1-es processzort tartalmazott.

Ez processzor a Sun új csúcsfegyvere, amely egy tokban nyolc CPU-t tartalmaz, amelyek összesen 32 thread futására tudnak hardverből "odafigyelni". A cég szerint az egyes magok órajelét nyugodtan felszorozhatjuk azok darabszámával, így szerintük ez a gép egy 8 GHz-esnek felel meg.

Aki mindezen felbuzdulva bevásárol ebből a gépből, jó ha tudja, hogy a fenti állítás nem igaz. Vagy legalábbis nem úgy. A lényeg, hogy a gép ereje a felépítésénél fogva csak azoknál az alkalmazásoknál jön elő, amelyek több szálon képesek futni és ezeknek a szálaknak (és így processzormagoknak) munkát is tudnak adni.
Sajnos rengeteg olyan alkalmazás van, amely erre képtelen, így senki ne csodálkozzon, mikor a csillogó, 9,6 GHz-es (esetünkben 8) gép elé leülve úgy érzi magát, mint a jó öreg PIII 450-esen.

Nézzük a szoftverkörnyezetet: a gépen mérkőző operációs rendszerek közül az egyik a világ legfejlettebb Unixa, a Solaris 10-es. Sajnos a Nevadát (leendő 11-es) nem volt időm kipróbálni, pedig rengeteg teljesítményjavító intézkedés történt benne.
A másik operációs rendszer a mostanában SPARC-on némileg hanyagolt bugware, név szerint a Linux.
Ez utóbbi csak nemrég képes futni ezen a platformon, de szerencsére az ubuntus csapat és Dave Miller kemény munkájának köszönhetően a Dapper Drake már hiba nélkül telepíthető és használható rajta. Köszönet nekik (és a Sunnak) ezért.
Az Ubuntu alapból egy erősen patchelt 2.6.15-ös kernellel érkezik, amelyből a stock verzió még futásképtelen a gépen. A leendő 2.6.17-es viszont már a kernel.org-os verzióban is használható.

Egy érdekesség adódott a Linuxszal, mégpedig az, hogy a 32 (virtuális) processzor helyett csak 24-et "látott". Tekintettel arra, hogy csak egy délutánom volt a tesztre, efölött erősen elítélhető módon elsiklottam.

A gépen ki szerettem volna próbálni a FreeBSD-t is, amely szintén gőzerővel készül erre a multicore-os szörnyetegre, de sajnos a fejlesztő szerint még alapvető problémák vannak a használhatósággal (nem lehet 16 MB-nál több memóriát igénylő programokat futtatni), így azt legnagyobb bánatomra mellőznöm kellett.

Csapjunk bele a lecsóba.

Az első teszt a sysbench nevű mindentudó benchmark program memóriatesztje volt. Ebben a tesztben eltérő blokkméretekkel végeztem tesztet.
Az első mérés a gyári 2.6.15-ös Linux kernellel történt:

Látható, hogy annak ellenére, hogy csak 24 processzort látott a kernel, a memóriasávszélesség 32 threadig nőtt, elérve a maximumot.

A következő teszt a 2.6.17-es (kernel.org-os) kernellel készült:

Nagy különbség nem látszik. Ezt követően megnéztem, hogy mit tud a gép Solarisszal:

Látható, hogy itt az 1kB-os blokkméretnél elfogyott valahol a szufla, így a két operációs rendszer összehasonlításához a 2k-s blokkméretet vettem alapul, mivel az a Linuxnál és a Solarisnál is párhuzamos a többivel és jobban szemügyre vehető a görbe eleje:

A görbe több szempontból is érdekes. Egyrészt az látszik, hogy a 2.6.17-es kernel néhol elég jelentősen eltér a 2.6.15-östől. Nem véletlen tehát, hogy többen is sportot űznek abból, hogy az egyes kernelverziók közötti sebességkülönbségeket figyeljék.
Másrészt elég egyértelműen látható, hogy aki sysbench-csel méri az e-pénisze méretét, az jobban jár, ha Solarison futtatja. A görbe csúcspontján, 32 szálnál kétszeres különbség jelentkezik, ami jelenthetné azt is, hogy a Solarist már rendesen optimalizálták erre a platformra, a Linuxot pedig még nem, azonban ugyanez az eltérés fennáll az operációs rendszer x86-os változatánál is. Aki kíváncsi a részletes magyarázatra, olvassa el a forráskódot.

A következő teszt ugyancsak a sysbench igénybevételével a MySQL adatbázisszerverrel történt. Elkerülendő, hogy a sysbench teljesítményét mérjem a MySQL-é helyett, ebben az esetben egy második gépet is igénybe vettem, amely egy közvetlen gigabites kanóccal volt a T2000-es fenekébe dugva. A tesztek így hálózaton keresztül történtek, a sysbenchet futtató gép minden esetben egy 32 bites Linux (Ubuntu) volt. A kliens gép két darab 2,6 GHz-es Opteronnal rendelkező szerver volt, amely így nem okozott szűk keresztmetszetet a sysbenchnél.

Első tesztünk azt hivatott eldönteni, hogy a MySQL 4.1-es verziója 32, vagy 64 bitesen gyorsabb-e Solaris 10-esen:

Azt hiszem a kérdés eldőlt. Sajnos az idő rövidsége és az Ubuntu kreténsége (vagy inkább az én hülyeségem) miatt Linuxon nem volt módom kipróbálni ugyanezt, így ott minden esetben 32 bites módban futott a MySQL.

Következő tesztünk kicsit összetettebb, SELECT teljesítményt mér egy 1 milliós HEAP táblán, azaz a tesztben nem szerepel semmiféle diszk IO.
Íme az ábra:

A teszt több kérdésre is megpróbál választ adni. Egyrészt szerepel benne Linux esetén egy MySQL 4.1 és 5.0 összehasonlítás, Solarisnál pedig ez kiegészül a beta verziós 5.1-gyel. Ezenfelül kíváncsi voltam a két kernel teljesítményére is.
A konfiguráció mindkét esetben megegyezett.

A görbéken túl sok mindent nem kell magyarázni. A Solaris vitte a pálmát ebben a tesztben a Linuxszal szemben, amely talán nem is olyan meglepő, figyelembe véve, hogy a Linux valószínűleg még kevésbé optimalizált a T1-esen, mint a Solaris. Utóbbi 512 kliens threadnél kb. négyszeresen rávert a Linuxra a MySQL 4.1-et futtatva.
Érdekes még megfigyelni, hogy a 4.1-5.0-5.1 vonalon a MySQL milyen szépen lassul, amely különösen feltűnő akkor, mikor sok kliens kérdez a szervertől.

Konklúzió: a Sun T1-es processzora haldoklik (szakáll kinő, haj kihull), mikor nem megfelelően párhuzamosítható munkát adunk neki és szárnyal, mikor legalább 32 szálon használjuk. A Sun a processzort elsődlegesen olyan helyekre ajánlja, ahol ez a párhuzamosság előállítható (webszerverek, adatbázisszerverek), amely ajánlást valóban érdemes megfogadni.
Hátránya az architektúrának (sok, lassú core), hogy az ellenfelekkel szemben (pld. két magos Opteron és Xeon) itt nem tudunk nagy teljesítményt kivenni a gépből, ha csak kevés szálon terheljük. Egy két magos Opteronnál néha már akár két, vagy négy szálon (de 8-nál már nagy biztonsággal) elérhető a maximális teljesítmény és a legrövidebb válaszidő, azonban ugyanehhez a T1-nél 32 aktív szál szükséges, amely nem biztos, hogy mindenhol megfelelő. Egy gyengén, vagy közepesen terhelt szervernél hiába fut 4-8 szálon a kiszolgálás, a gép csak a teljesítménye felét képes leadni, a válaszidők ezáltal lassabbak lesznek mint egy ennek megfelelő teljesítményű Opteron, vagy Xeon processzoron.

Példaként említhetném a HUP adatbázisát, ahol nagyon ritka, hogy kettőnél több query fusson egy időben. Ahhoz tehát, hogy ez a gép jó befektetés legyen, ennél jóval nagyobb terhelést kell neki biztosítani.