Most, hogy a FreeBSD-ben lassan használható lesz játékra a ZFS, sokakban felmerülhet a kérdés, hogy mennyire sikerült a portolás teljesítmény szempontjából.

Bár a ZFS nem épp a sebességéről híres :), azért a legtöbb feladatra annyira nem is rossz. Mennyire sikerült tehát elrontania Pawelnek, Kipnek és úgy általában a FreeBSD-nek ezt a nagyon várt fájlrendszert?

Mint mindig, pontos válasz erre sem adható, mindenkinek saját magának kell kimérnie. Én a reprodukálhatóság kedvéért a sysbenchet használtam, annak is a fileio modulját.

A gép, amivel próbálkoztam egy meglehetősen elterjedt darab, HP DL380G5 (még egy korábbi szériából), benne HP SmartArray P400-as RAID vezérlő, rajta akksival védett 512 MiB cache, amelyet az alapértelmezett 3/4-es felosztásban használt írásra és olvasásra. A diszk, amit hajtottam, egy RAID0-ba rakott (a vezérlőben nem tudok passthrough eszközt definiálni, így valamilyen tömböt létre kellett hozni) egy darab 72 GB-os 15k fordulatszámú diszk volt.

Az oprendszereket FreeBSD oldalon egy friss -CURRENT(/amd64), míg az OpenSolaris részéről a 2009.06-os release képviselte.

Azért, hogy az OS cache-t kivédjem, a sysbenchnek azt mondtam, hogy minden írás után fsync()-eljen, illetve olyan mennyiségű adattal dolgoztattam meg, amelyik legalább egy nagyságrenddel nagyobb volt a gépben lévő memóriánál (azaz pld. 4 GiB RAM-ra 40 GiB adatmennyiség).

A sysbench fileio modulja képes több szálon is futni, azonban ezeket a teszteket csak egy szálon hajtottam végre. A teszt során a program méri többek között az átviteli sebességet (amely a blokkmérettel ide-oda átváltható MiBps-re és IOPS-re, azaz tranzakcionális sebességre) és a válaszidőt is, azaz azt, hogy egy művelet milyen gyorsan zajlott le. Ez utóbbi főleg a véletlenszerű műveleteknél fontos, hiszen hiába olvas gyorsan a diszk, ha lassan pozicionálja a fejet, és ha sávot kell váltani hosszú ms-okat szüttyög vele.
A sysbench a következő -élettől némileg elrugaszkodott- teszteket tudja: rndrd (véletlenszerű olvasás), rndrw (véletlenszerű olvasás-írás, ilyenkor a kettő közötti megoszlás alapból: R/W=1,5), rndwr (véletlenszerű írás), seqrd (folyamatos olvasás), seqrewr (folyamatos újraírás), seqwr (folyamatos írás).

Lássuk a medvét!

IOPS-ben mérve a két rendszer látszólag fej-fej mellett halad, általánosságban azonban kimondható, hogy egy hajszálnyival szinte mindig az OpenSolaris a nyerő.

A hatalmas IOPS értékek alacsony blokkmérettel leginkább a SmartArray kontroller cache-ének köszönhető, hiszen szekvenciális olvasáskor képes felismerni ezt a mintát, és előre dolgozni (a fájlrendszertől függetlenül), illetve íráskor is ahelyett, hogy rögtön a diszkre kellene tennie mindent, elteheti a cache-ében, visszaigazolhatja az írást, majd azokat összefogva, nagyobb mennyiségben delejezheti rá a lemezekre.

Szépen előjön a random teszteknél a diszkek -leginkább- seek idejéből adódó alacsony IOPS is, amely olvasásnál valahol a 170-es érték körül mocorog, míg írásnál 120 körülire esik.

Érdekesség a random írás tesztben a 128 kB-nál látható magas kiugrás. A zfs alapértelmezett blokkmérete ennyi, így tényleg megfontolandó ezt az értéket az alkalmazáshoz hangolni, mint látható, igen brutális növekedést jelenthet.

Szépek-szépek a fenti értékek, de az átlagembernek nem az IOPS, hanem az áteresztőképesség mond valamit. Nézzük a fenti számokat megabájt per másodpercben (MiBps)!

Mint látszik, lényegi különbség nincs a FreeBSD és az OpenSolaris között, kivéve a szekvenciális olvasást, ahol az IOPS ábrán látható hatalmas számok láthatatlanná tették a különbséget, amely most szépen előjött. Bár a grafikonon látványos eltérés adódik, az "csak" pár MiBps különbség, amelyet tovább növel (vizuálisan), hogy ez az egyetlen kiegyensúlyozott grafikon, ahol nincs nullához közeli érték, így az y origó is feljebb csúszott.

Végül nézzük meg, hogy mennyit kell várnia az alkalmazásnak a tesztben szereplő blokkokra:

Az y skálán logaritmikus léptékkel látható a válaszidő, azaz az az idő, amely a művelet indítása és lezárása között telt el, ezredmásodpercben.

Minden időértéknek három kategóriája van: a legkisebb, az összes érték átlaga, és a kérések 95%-át adó érték. A maximumokat nem tüntettem fel, mert néhol nagyon magasak voltak, és azt gondoltam, hogy a kérések 95%-át reprezentáló érték is jól kell, hogy jellemezze a teljesítményt.

Jelentősebb eltérések (meglepetés!) itt sincsenek, nem is lehetnek, hiszen annak a fenti grafikonokon is látszaniuk kellene.

A legérdekesebb a random read és write grafikon lehet, hiszen a legtöbb workload ilyen mintát mutat. Átlagértéke a gyártó által megadott átlagos seek time körül van, azaz nem hazudtak, mikor eladták nekünk ezt a diszket. :)

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.