Egy rövid bemutatkozás erejéig nálunk járt a HP legnagyobb (minden értelemben) x86-os rackmount gépe. Teszt.

A gép
A HP x86-os szerverportfóliója hagyományosan három, újabban négy kategóriára osztja a gépeket. Az ML széria a jellemzően SMB-knek szóló torony szervereké, a DL a kis-nagy rackmount szervereket kínálja, míg a BL az eddig két (egymással nem kompatibilis) blade infrastruktúrát fedi a régebbi p, és az újabb c osztályú eszközökkel.
A portfólió legfiatalabb eleme az SL, amely a masszív horizontális skálázódásra képes területeket ("web 2.0", HPC) célozza.

A tesztre kapott gép, a HP DL785G6 a DL széria 700-as sorozatának egyedüli (már amennyiben a korábbi, G5-ös generációt nem számítjuk külön), és jelenleg legújabb tagja, amely a high endet képviseli (1xx: low end, 3xx: entry-midrange, 5xx: mid-high, 7xx high end).

A géppel ugyan az x86 (jelenlegi) határait nem tudjuk feszegetni, de teljesítményben, és skálázhatóságban közel juthatunk vele az elvi maximumhoz, hiszen a benne alkalmazott Opteron processzorok nyolc foglalatig képesek kiegészítő logika nélkül összekapcsolódni.

A nálunk járt konfiguráció egy szerényebb kivitel volt, hiszen "csak" négy darab Opteron 8431 (2,4 GHz, hat mag, 3 MB L2, 5 MB L3 cache) processzort, és 32 GB memóriát tartalmazott, ahogy azt induláskor közli is velünk.

Mire jó?
Az első kérdés, amely ezzel a monstrummal kapcsolatban eszembe jutott ez volt: mire jó?
A kérdés megválaszolásához készítettem egy kis segítséget az alábbi kép formájában:

A képen balról jobbra egy HP C7000-es (teletömve BL685c G6-tal), a tesztben szereplő DL785G6, és a Sun X4640-es gépe látható. A konfigurációk hatékonyságának megértésében az alábbi táblázat segíthet:

Mérethatékonyságban a Sun rackmount gépe nyer, a HP-ban egyedül a méretéből eredő paraméterek (PCI és diszk slotok száma) magasabbak. Ha ezeket nem vesszük figyelembe, mindet veri viszont a blade kivitel. Lehet persze azt mondani, hogy ha csak egy (kevés) gépet veszünk, a blade nem hatékony, viszont ott, ahol DL785-öt használnak nem valószínű, hogy ez a gép egyedül van a gépteremben.
Természetesen a helyarányos teljesítmény nem minden, hiszen a HP-nak jelenleg nincs 8 CPU-s x86-os blade megoldása, így akinek szüksége van egy gépben ennyi CPU-ra (vagy memóriára), annak ebben a pillanatban rackmount gépet kell vennie.
A HP maga adatbázisok alá, illetve konszolidációs céllal (virtualizációra) ajánlja a gépet, amelyből a másodikra szerintem a blade-ek hasznosabbak, ha pedig egy virtuális gépben futó környezetnek 256 GB-nál több RAM-ra, vagy 4 CPU-nál többre van szüksége, valószínűleg amúgy is érdemesebb valódi szerverre tenni (elbukva persze a nagyobb flexibilitást, amit azért a blade-ek tudnak valamelyest ellensúlyozni).

Látszólagos teljesítmény
Ha a HP szerint az adatbázis, és a virtualizáció a cél, próbáljuk hát ezt a területet. A gépet egy távoli géptermünkben sikerült utolérnem, "gyári" állapotában egy VMware ESX 4-es volt rajta, amelyen egy 6 processzoros (azaz valójában egy CPU, hat mag) virtuális gépet teszteltem elsőnek. A storage egy HP EVA, amelyről a kiajánlott LUN-okat az ESX shared fájlrendszerén tárolt virtuális diszk image-ek tárolására használta, ezek jelentek meg a virtuális gépekben is.

Bemelegítésként a 6 processzoros (magos) virtuális gépben futó Red Hat EL 5.4-esre telepítettem egy MySQL 5.5.2, és PostgreSQL 8.4.3 adatbáziskezelőt, továbbá a teszteléshez szükséges sysbench programot. Az adatbázisok az EVA-ról kiajánlott LUN-okon laktak, ext3 fájlrendszeren.
A teszt után az ESX helyére felkerült ugyanaz az RHEL 5.4 verzió, ami korábban a virtuális gépben futott, a processzorok számát 6-ban limitáltam, és azonos paraméterekkel újraindítottam a tesztet.
Az eredmények MySQL read only és read write:

és PostgreSQL esetén:

Sajnos a Postgres RW-tesztek annak ellenére meglehetősen nagy varianciát mutatnak, hogy minden teszt ötször futott, és ezek közül a FreeBSD ministatjának 99.5%-os konfidencia-szintjére adott eredmény került felrajzolásra.

Az azonban szépen látszik (főleg a CPU-korlátos read only teszteknél), hogy a virtuális gépben futó adatbázisszerverek jóval lassabbak voltak a valódi vason futó társaiknál. Számszerűleg a MySQL RO (CPU korlátos) esetben a virtuális verzió teljesítménye átlagosan 78%, RW esetben 89%, Postgres RO-nál 86%, RW-nál pedig 91%-a volt a VM nélküli futásnak.

A kedvenc OS
Nem maradhat ki természetesen a FreeBSD sem a tesztelésből. A 8-as verzióban bemutatkozott topológiát értő ULE schedulernek van még hová fejlődnie, hiszen az Opteron topológiáját az ütemező rosszul ismeri fel, és azt hiszi, hogy minden egyes CPU-nak osztott L2 cache-e van az egyes magok között, L3 cache pedig egyáltalán nincs, holott a valóság az, hogy a 8400-as Opteronnál minden egyes magnak dedikált L2 cache-e van, és ezek felett van egy közös L3 cache.

A felismerés szerencsére könnyen javítható, egy pár soros kernelpatch után a megfelelő topológiát ismeri fel a kernel. Rögtön adódik a kérdés, hogy ez mennyire befolyásolja a teljesítményt, hiszen egy megfelelő ütemező az egyre nagyobb, és bonyolultabb elrendezésű cache-ek jó kihasználtságát csak a hierarchia ismeretében tudja biztosítani.

A helyes (vagy helytelen) cache topológia felismerése közötti teljesítménykülönbséget a MySQL és PostgreSQL teljesítményének mérésével próbáltam felderíteni.
MySQL:

PostgreSQL:

Mint látható, a kép elég vegyes, ami több dolgot is valószínűsíthet:
- az ULE nem annyira fejlett, hogy képes legyen hasznot húzni ebből a tudásból
- a topológia helyes ismerete (ezeknél az alkalmazásoknál legalábbis) annyira nem fontos

Evolúció
A RHEL 5.4-ben lévő ősrégi (és agyonpatchelt) 2.6.18-as Linux kernel felett már alaposan eljárt az idő, míg a hamarosan megjelenő Ubuntu 10.04 2.6.32-es zsírtól csillogó kernele még csak nemrég jött le a futószalagról. Érdekesnek tűnt összehasonlítani a kettőt.
MySQL-lel:

és PostgreSQL-lel:

Ezek szerint az öreg, plasztikázott "anyuci" is tud úgy kinézni, mint a húszas egyetemista. Vagy még jobban is.

Nyissunk ablakot!
MySQL (és Postgres) teszteket már sok gépen futtattam, viszont már nagyon rég volt, hogy Windowst (akkor még 2003-ast) is teszteltem volna.
Letöltöttem tehát a legújabb Windows 2008 (R2) szerver DVD-jét a Microsofttól, felraktam az OS-t a gépre, és nekikezdtem az ssh elérés (cygwin), sysbench (Visual Studióval) és a MySQL (natív bináris) telepítésének.
Legnagyobb meglepetésemre -a FreeBSD után- a legkevesebb időt vette igénybe ennek összeállítása, mindezt úgy, hogy sysbenchet most tettem először Windowsra (a legfájdalmasabb Solarisra lefordítani), mivel múltkor hálózaton keresztül teszteltem, így akkor a windowsos gépen csak a MySQL futott, ebben a tesztben viszont minden alkalommal "helyben" volt a sysbench és a DB is (köztük unix socket, Windowson pedig named pipe, hogy a TCP overheadjét elkerüljem).

Első tesztként (hogy lássam, mennyire gyatra a sysbench windowsos teljesítménye) egy memória benchmarkot futtattam sok szálon, amely szépen megizzasztotta a gépet:

Ezek után rendben végigment ezen az OS-en is az összes teszt.

Delfin és elefánt a nyitott ablaknál napozó ördögi pingvinnel
A DL785-ben lévő Opteronoknak a (régebbi, 7xxx-es) Xeonokkal szembeni egyik legnagyobb előnye a nagy memóriasávszélesség, a sysbenchnek pedig van egy ilyen -értelemszerűen a valósággal nem túl szoros kapcsolatot ápoló- memória tesztje.
Lássuk:

Érdekes módon kis blokkméretekkel a Windows mindenkit legyaláz, aztán hamar átveszi, és végig meg is tartja az elsőséget a FreeBSD. A Solaris az abszolút vesztes ebben a tesztben, az Ubuntu csak a kis blokkos részen tud ráverni, egyébként ahhoz hasonló teljesítményt nyújt.
Az igazi meglepetés -számomra- itt a Windows volt, hiszen a sysbenchnek nem az elsődleges platformja. Hogy itt a Visual Studio, vagy a Windows okozta-e ezt a kiemelkedő teljesítményt, nem tudom. Sokat rugózni viszont nincs értelme ezen, mégiscsak egy szintetikus teszt...

Érdekesebb talán ugyanez az adatbázisszerverekkel, MySQL-lel:

és Postgresszel (Windowson nem teszteltem):

A MySQL-es eredményekben túl nagy meglepetés nincs, szokás szerint a Linux a nyertes -bár én személy szerint azon csodálkoztam, hogy a 2.6.18-as kernellel szerelt OS így rávert az újabb kiadásra-, és a FreeBSD most valahogy nem hozta a formáját, még a Solaris is gyorsabb tudott lenni nála. A Windows RO MySQL teljesítménye eléggé egysíkú, de a tippem az, hogy ez inkább a MySQL portjának tudható be, mintsem a Windows gyatra skálázódásának.

Vélemény
A gép vegyes érzelmeket keltett bennem. Ahhoz képest, hogy mekkora -fizikai méreteiben-, jól látszik, hogy lehetne nagyobb is. 16 CPU, 1-2 TB memória... igaz előbbihez már kevés lett volna "összedrótozni" a CPU-kat, viszont az "x86 monster" jelzőre a külső alapján így jobban rászolgált volna a belsővel. Mellé téve a Sun szerverét, jobban érthető, hogy mire gondolok.
Nem érzem túl nagynak a blade-ben elérhető kapacitáshoz képest sem, és ezt elsősorban azért mondhatom, mert a HP által (is) "webkettes"-nek nevezett világban egyre kevesebb szükség van a nagy mosógépekre, a hangsúly inkább a horizontális skálázódáson van, amelyhez viszont ideálisak a kisebb, két CPU-s blade-ek.
Ezek a két CPU-s, 12-24 magos, negyed TB-nyi RAM-ot tartalmazó blade-ek pedig akkora teljesítményt nyújtanak, mint pár éve egy "nagyvas", ráadásul olcsók, könnyen kezelhetők, és standard alkatrészekből állnak. Azaz egyre feljebb tolják azt a határt, ahol azt mondja az ember, hogy itt már érdemes "nagy" gépet venni.

Ha választanom kellene, inkább egy teletömött C7000-est szeretnék.

És te?