ZFS – Stressitestausta ja flashin vaikutus

ZFS:ää voi nopeuttaa lisäämällä SSD-levyn välimuistilaitteeksi. Toinen nopeutuskeino on lisätä flash-muistia lokilaitteeksi. Vaikka kymmenen kiintolevyn raidz2-järjestelmä on erittäin nopea suurten tiedostojen käsittelyssä, teoriassa jopa 8 kertaa nopeampi kuin yksi levy, on pienten tiedostojen käsittelyn nopeus teoriassa sama kuin yhden levyn. Sen takia pienikin määrä kiintolevyyn verrattuna hakunopeudeltaan ylivoimaista flash-muistia kriittisessä paikassa voi nopeuttaa koko järjestelmää selvästi. Kumpi sitten on tärkeämpi, välimuisti vai lokilaite? Entä kuinka suuri sen pitäisi olla? Lokilaitteen ei tarvitse olla suuri, mutta välimuistilaitteen koolla on jo väliä.

Testauksen tavoitteet

Evaluointivaiheessa kopioitiin 8 Tt tiedostoja Linux-koneelta ja ensimmäisellä kerralla kopiointi hidastui matkan varrella huomattavasti. Tiedostoja oli noin 1,6 miljoonaa, joten varsin helposti heräsi epäilys, että tiedostojen määrällä olisi ollut vaikutusta hidastumiseen. Kopiointi toistettiin, mutta silloin ZFS:llä oli käytössä erilliset välimuisti- ja lokilaitteet eikä hidastumista enää esiintynyt. Nämä olivat havaintoja, joiden taustalla ei ole mittaustuloksia eli lähes MUTUa. Jotta asia selviäisi, paras testi olisi luoda erittäin suuri määrä tiedostoja ja mieluummin pieniä, jotta testin ajoaika olisi mahdollisimman lyhyt.

Toinen tavoite oli selvittää flash-muistin vaikutus nopeutuksessa. Usean levyn RAID-pakan kirjoitus- ja lukunopeudet ovat erinomaiset, mutta hakuaika tai IOPS (Input/output Operations Per Second) on yhtä huono kuin yhden levyn. Flash-muistin siirtonopeudet eivät yleensä häikäise, mutta IOPS-luvut ovat aivan eri tasolla. Täytyy kuitenkin muistaa, että kiintolevyjen apuna on aina keskusmuistipohjainen välimuisti, joka on vielä vikkelämpää kuin flash-muisti, joten flashillä ei välttämättä kovin suuria parannuksia saavuteta. Myös tässä paras testi on mitata pienten tiedostojen käsittelyn nopeutta.

Kolmas tavoite oli selvittää, voisiko melko arvokkaan SSD-levyn korvata halvemmalla vaihtoehdolla. Aluksi tämä tavoite oli lähinnä etäinen toive, mutta sen järkevyys nousi esille varsin pian.

Käytettyjen laitteiden luku- ja kirjoitusnopeudet on myös tietysti hyvä testata, vaikka niillä ei tavoitteiden kannalta olisikaan merkitystä, niiden testaus on vain niin nopeaa ja helppoa ja lisäksi mittaustulokset auttavat hahmottamaan kokonaiskuvaa.

Testimenetelmät

Edellä mainittu kopioinnin hidastuminen johtui mitä ilmeisimmin metadatan käsittelystä. Voisiko syy olla hakemistopuun rakenteessa? Erittäin syvä hakemistopuu tai erittäin paljon tiedostoja yhdessä hakemistossa?

Hakemistopuun ja tiedostojen luominen olisi helppo toteuttaa skriptin avulla, mutta tarve on niin ilmeinen, että siihen löytyi valmis skripti: https://computing.llnl.gov/code/sio/tarballs/fdtree-1.0.2.tar.gz . En löytänyt sitä suoraan vaan Linux Magazineen ( http://www.linux-mag.com ) kirjoittaneen Jeffrey B. Laytonin ( http://www.linux-mag.com/author/311/ ) artikkelin ( http://www.linux-mag.com/id/7497/ ) kautta.

Linux Magazinen julkaisu on valitettavasti lopetettu kesällä 2011, mutta vanhat artikkelit ovat edelleen luettavissa ja Jeffrey B. Layton jatkaa kirjoittamista enterprisestorageforum:ssa ( http://www.enterprisestorageforum.com/author/Jeffrey-Layton-2040.htm ).

Hakuammuntaa

Yritin siis etsiä hakemistorakennetta ja tiedostomäärää, jolla hidastuminen ilmenisi. Erilaisten hakemistopuurakenteiden testitulokset vaihtelivat, mutta IOPS pysyi samana (tästä lisää myöhemmin). Koska samalla oli tarkoitus testata myös flash-muistin vaikutusta eri tavoin, testiajon pituudella oli käytännön rajoitus, aikaa ei saisi kulua tuhottoman paljon. Pisin testiajo, johon päädyin oli 29 miljoonan tiedoston luonti ja se vei yli kaksi vuorokautta aikaa. Fdtree ei anna välituloksia ja sen takia testin aikana mahdollisesti tapahtuva hidastuminen jäisi huomaamatta. Tämän puutteen poistamiseksi tein pienen skriptin:

#!/bin/sh
for i in `seq 200`
do
   sleep 30m
   df | awk ’/tank/{printf $3″  ”}’
   date
done

Skripti tulostaa puolen tunnin välein testattavan tiedostojärjestelmän vapaan tilan sekä kellonajan ja tekee niin sadan tunnin ajan. Jos skriptin tulosteen ohjaa komennolle:

awk ’{if (PREV) print ($1-PREV)/4/1800 ; PREV=$1}’

tulostuu kuinka monta tiedostoa on luotu tai kuinka monta kertaa hakemistojen metadataa on kasvatettu keskimäärin sekunnin aikana kunakin edeltävänä puolena tuntina.

Hidastumista ei kuitenkaan ilmennyt. Skriptistä oli kuitenkin se hyöty, että se näytti, että vapaa tila väheni melko tarkalleen yhtä nopeasti hakemistopuun rakenteesta huolimatta. Syvässä hakemistopuussa hakemistojen metadataa jouduttiin päivittämään useammin ja sen takia tiedostojen luonti oli hitaampaa. Matala ja leveä hakemistopuu on tavallaan tehokkaampi. Siinä metadatan osuus on pienempi tiedostojen määrään verrattuna.

Testausta hidastumisen etsintä kuitenkin hidasti. Kunkin konfiguraation yksi testiajo kesti tosiaankin yli kaksi vuorokautta. Lisäksi alussa kokeilin erilaisia hakemistopuumalleja enkä heti alussa päätynyt siihen, että 29 miljoonaa tiedostoa on riittävän paljon, vaan kokeilin ensin vaatimattomammilla määrillä. Siinä sitten vierähti viikko jos toinenkin..

Näiden testien tulokset ovat ensimmäisessä kuvassa. Testin käynnistänyt komento oli ”fdtree -d 90 -f 40 -s 1 -l 3” ja se tulosti käynnistäessään:

fdtree-1.0.2: starting at ./LEVEL0..12798/
        creating/deleting 3 directory levels with 90 directories at each level
        for a total of 737191 directories
        with 40 files of size 4KiB per directory
        for a total of 29487640 files and 117950560KiB

Kuvaajaa tulkittaessa on huomattava, että tiedostojen luontiin käytettiin selvästi eniten aikaa. Se on siis kaikkein tärkein tulos. Hakemistoja luodaan harvoin niin suuria määriä kerralla, että nopeudella olisi suurta merkitystä. Käytännössä hakemiston luonti oli yhtä nopeaa kuin tiedoston luonti, mutta Linuxin ext4:llä se oli hieman nopeampaa. Ext4:n tuloksia ei oikeastaan olisi pitänyt laittaa samaan kuvaajaan, koska sen testiajot tehtiin toisessa, selvästi nopeammassa koneessa. Kiintolevyt ja niiden määrä olivat kuitenkin lähes identtiset ja hyvin suurella todennäköisyydellä Linux-koneen nopeampi keskusmuisti oli suurin selittäjä paremmille tuloksille tiedostoja ja hakemistoja luotaessa. Niiden poistossa ext4 oli selvästi hitaampi, joten ainakin siltä osin testi todisti, että ZFS on parempi. Tiedostojen ja hakemistojen luomisen osalta en uskalla edes arvailla kumpi tiedostojärjestelmä on parempi.

Flash-muistin vaikutusta testattiin usealla eri tavalla. Tuloksissa huomiota herätti se, että ne ovat lähes identtisiä. Jos flash-muistia käytetään ZFS:n apuna, se nopeuttaa, mutta sillä ei näytä olevan väliä, onko se välimuisti- vai lokilaitteena. Lisäksi 8 gigan kokoinen USB-tikku, vaikkakin nopea sellainen, nopeuttaa yhtä paljon kuin 60 gigan huippunopea SSD-levy. Silläkään ei ollut merkitystä, jos sekä välimuisti- että lokilaitteena oli flash-muistia.

Laitteiden nopeudet

Tallennuslaitteilla on käyttöjärjestelmän kannalta vain kaksi mielenkiintoista ja siis testaamisen arvoista ominaisuutta: siirtonopeus ja hakuaika. Siirtonopeus on hyvin helppo testata ja sen vaikutus on helppo ymmärtää. Hakuaikaa on vaikea testata eikä sen vaikutusta käytäntöön ole helppo ymmärtää. Edellä on yritetty havainnollistaa hakuajan merkitystä. Hakuajan vaikutusta on yritetty kautta aikain minimoida välimuisteilla eri tasoilla ja eri tavoin. Tallennuslaitteen pitkä hakuaika on siis periaatteessa huono asia, mutta käytännössä sen vaikutusta harvoin näkee. Hakuaikaa hieman käytännöllisempi suure on IOPS. Sekään ei ole helposti suoraan mitattava arvo. Jos esimerkiksi luetaan tiedostoa, on metadatan käsittely yksi tai useampi IO-operaatio, johon ei vaikuta pelkästään hakuaika, metadata pitää myös lukea. Kun tiedoston sijainti on löytynyt, pitää sekin lukea. Käytännössä kaikki tiedostojärjestelmässä tehtävät haut ja muut operaation vaativat useita muita operaatioita ja hakuaikojen lisäksi nopeuteen vaikuttaa myös luku- tai kirjoitusnopeus. Kirjoitus- ja lukunopeus sen sijaan ovat hyvinkin tarkkaan samat kuin suuren tiedoston kirjoitus- ja lukunopeus.

Mittaustulokset ovat kolmannessa kuvaajassa. Koska tulosten hajonta on hyvin suuri eikä kuvaajassa näy tarkkoja arvoja, ovat tulokset myös alla taulukkona:

    Pelkät kiintolevyt       SSD     USB    Linux, ext4
Kirjoitus           207        198       8,6    316
Luku                283        529      32,5    352

Flash-muistin vaikutus ZFS:n nopeuttajana – toinen testisarja ja loppupäätelmät

Yli kahden vuorokauden ajoaika testille on hankala. Jos testattavia vaihtoehtoja on useita, menee ikä ja terveys. Toisaalta testin ajoaika ei saa olla liian lyhytkään, muuten sen luotettavuus ja tarkkuus kärsii. Vaihtoehtoja haarukoidessa muutama minuutti olisi sopiva. Tiedostojärjestelmää testatessa pitää kuitenkin pitää aina mielessä se, että keskusmuistia käyttävä välimuisti sekoittaa helposti testitulokset, joten joko sen vaikutus pitää ohittaa testausjärjestelyiden avulla tai testiajon pituus pitää olla melko pitkä. Päädyin komentoon ”fdtree -d 3 -f 16 -s 1 -l 10”, jonka ajoaika oli käytetyillä laitteistoyhdistelmillä kahden ja kolmen tunnin välillä. Eräs tärkeä syy valintaan oli se, että sen vaatima tallennustila mahtui USB-tikulle.

Testin käynnistänyt komento  ”fdtree -d 3 -f 16 -s 1 -l 10” tulosti käynnistäessään:

fdtree-1.0.2: starting at ./LEVEL0..3481/
        creating/deleting 10 directory levels with 3 directories at each level
        for a total of 88573 directories
        with 16 files of size 4KiB per directory
        for a total of 1417168 files and 5668672KiB

Mittaustuloksista huomataan, että USB-tikku ZIL- eli lokilaitteena antoi paremman tuloksen kuin välimuistina ja vain aavistuksen verran huonomman kuin SSD-levy lokilaitteena. Ensimmäisessäkin testisarjassa USB-tikku lokilaitteena oli vain aavistuksen verran heikompi kuin SSD-levy lokilaitteena. Jos flash-muistia halutaan käyttää, on USB-tikku lokilaitteena lähes paras sekä helppo ja halpa valinta. Tässä testisarjassa nousee kuitenkin esille se, että keskusmuistia käyttävä välimuisti riitti ja kiintolevyt ilman flash-muistia olivat yhtä nopeita kuin SSD-levy. Myös Linux-koneessa keskusmuistia käyttävä välimuisti näytti kyntensä ja sen kaikki tulokset ovat selvästi parempia kuin hitaampaa keskusmuistia käyttävän OpenSolaris-koneen. Vaikka flash-muisti ei tässä testisarjassa nopeuttanut, ei se myöskään hidastanut ja parin kympin arvoinen USB-tikku on halpa vakuutus sille, että tiedostojärjestelmä ei hidastu erittäin raskaissa operaatioissa.