ZFS – Flash on keskusmuistia hitaampaa

Deduplikointi vaatii paljon muistia, mutta SSD-levyllä voi ”jatkaa” usein rajallista ja liian pientä keskusmuistia. Flash-muisti ei kuitenkaan ole yhtä nopeaa kuin keskusmuisti, joten deduplikointi hidastaa silti siinä vaiheessa, kun keskusmuistipohjainen välimuisti ei enää riitä. Kuinka paljon se sitten hidastaa? Tämä riippuu tietysti laitteistosta – kuinka nopeaa keskusmuisti on suhteessa SSD-levyyn. Käyttämässäni laitteistossa keskusmuisti on melko hidasta, tyyppiä DDR-400. Kaikki levyt sen sijaan ovat nopeita, käytännössä uusia ja SSD-levy varsinkin on käytännössä niin nopea kuin vain kohtuullisella hinnalla kaupasta saa. Ainoastaan suoraan PCI-e-väylälle liitettävät flash-kortit olisivat selvästi nopeampia. Tuloksissani deduplikointi hidastaa siis vähemmän kuin tasapainoisemmassa laitteistossa.

Testijärjestelyt

Aiemmin käytetty fdtree-skripti kirjoittaa luomiinsa tiedostoihin pelkkiä nollia. Ne deduplikoituvat täydellisesti lukuunottamatta ensimmäistä blokkia tai tiedostoa, jos ne ovat pieniä. Sitä pitää siis muuttaa, jotta testitiedostot eivät deduplikoituisi. Käytännössä tein siitä kuitenkin kopion nimellä fdtree-urand ja muutin dd-käskyn lähteeksi /dev/urandom-pseudolaitteen. Alkuperäinen versio on hyvä verrokki, sillä normaalikäytössä suositusten mukaan ainakin puolet blokeista pitäisi olla deduplikoituvia. Alla muutettu rivi:

dd if=/dev/urandom bs=4096 count=$fsize of=$file_name > /dev/null 2>&1

Ideaalitilanteessa deduplikoituvuus tiedettäisiin etukäteen ja testiohjelma tuottaisi juuri sen verran deduplikoituvaa materiaalia. Varsin työläs tapa olisi tehdä skriptivariaatioita tai lisäparametri deduplikoituvuusasteille ja ajaa testit esimerkiksi asteille 2, 3, 4 jne. Ääripäät antavat kuitenkin jo jonkinlaista tuntumaa.

Toinen skriptimuutos liittyy siihen, että tein erillisen datasetin (käytännössä uusi alihakemistopuu, jonka ominaisuuksia, kuten deduplikointia, voidaan muuttaa) testausta varten. Muutin myös raportointiväliä dftrack-skriptissä:

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

Uusi dataset luotiin ja asetusta muutettiin käskyillä:

zfs create tank/dedup
zfs set dedup=on tank/dedup

Edellä esitelty dftrack-skripti käynnistettiin komennolla:

sh /usr/local/bin/dftrack | awk ’{if (PREV) print ($1-PREV)/4/300 ; PREV=$1}’  &

Sen jälkeen itse testiohjelma:

fdtree-urand -d 50 -f 80 -s 1 -l 3
fdtree-1.0.2: starting at ./LEVEL0..29938/
        creating/deleting 3 directory levels with 50 directories at each level
        for a total of 127551 directories
        with 80 files of size 4KiB per directory
        for a total of 10204080 files and 40816320KiB

Tiedostoja on siis hieman yli 10 miljoonaa.

Alkuperäinen fdtree käynnistettiin samoilla parametreillä.

Tulokset ja niiden tulkinta

Ensin fdtreen tulokset taulukkona.

                                          fdtree-urand fdtree
Directory creates per second         217   212 
File creates per second                    67   192
File removals per second               353  1988
Directory removals per second     2406  2362
Kokonaisaika/s                        181014 58661

Hakemistojen luonti ja poisto on yhtä nopeaa, joten ne ovat testin kannalta turhia tuloksia. Lisäksi kokonaisaikaan niillä on mitätön merkitys. Tiedostojen käsittelyssä ero on sen sijaan suuri. Tiedostojen poisto on melko nopeaa, mutta siinä suhteellinen ero on hyvin suuri. Kokonaisajan kannalta sen merkitys on kuitenkin melko vähäinen. Tiedostojen luonnin nopeus on koko testin kannalta tärkein, ja siitä on erillinen graafi. Kun vertailee tiedostojen luonnin nopeuksien suhdetta ja kokonaisaikojen suhdetta, pitäisi huomata, että se on hyvin tarkalleen sama. Tiedostojen luontinopeus dominoi siis koko testiä.

Graafissa ei ole vaaka-akselilla asteikkoa, koska se ei olisi tarkka. Se on kuitenkin aika-akseli ja kuvaajien pituudesta voi päätellä testiajojen viemän ajan. Punaisen kuvaajan alussa on yksi alhainen mittapiste, joka johtuu mainitusta epätarkkuudesta ja se olisi pitänyt oikeastaan poistaa virheellisenä. Samaa voisi uumoilla sinisenkin alkuosan kuopasta, mutta se todennäköisimmin on samaa vaihtelua, joka näkyy koko kuvaajassa. Jos mittausväli olisi ollut suurempi kuin 5 minuuttia, ei vastaavaa ”sahausta” olisi näkyvissä.

Graafissa merkittäviä havaintoja on se, että deduplikoituvan materiaalin kirjoittaminen on aina hieman nopeampaa kuin deduplikoitumattoman. Jos deduplikoinnin käyttämä metadata on ensisijaisessa välimuistissa, on ero kuitenkin melko pieni. Toisin olisi, jos tiedostojen koko olisi suurempi. Silloin tiedoston vaatiman uuden metadatan kirjoittaminen olisi pienempi operaatio verrattuna itse tiedoston kirjoittamiseen.

Deduplikoitumattomien tiedostojen kuvaajassa tapahtuu melko jyrkkä lasku eli hidastuminen. Se, missä vaiheessa hidastuminen tapahtuu, riippuu siitä, miten paljon välimuistia on jo aiemmin käytetty eli siis kuinka kauan koneen käynnistymisestä on aikaa ja kuinka paljon tiedostojärjestelmiä on käytetty. En käynnistänyt konetta uudelleen ennen testiä, joten hidastumispiste on sattumanvarainen eikä siitä kannata vetää johtopäätöksiä. Muita vaikuttavia tekijöitä ovat keskusmuistin määrä ja sitä kautta välimuistin määrä ja tietysti välimuistin asetukset. Tärkeä havainto on hidastumisen määrä. Nopeus tippuu melko tarkalleen kolmannekseen. Mutta, kuten jo alussa huomautin, tulos on epätavallisen hyvä johtuen hitaasta keskusmuistista ja nopeasta SSD-levystä. Uudemmalla laitteistolla kymmenesosaan tai sitäkin pienempään hidastuminen olisi odotettavaa.

Loppupäätelmät

Tuloksia tulkitessa on otettava huomioon testilaitteiston erikoisuus. Sen takia SSD-levyllä tulokset ovat liian hyviä. Toisaalta testi oli täysin synteettinen ja tiedostot epätavallisen pieniä. Suurilla tiedostoilla erot nopeuksissa olisivat pienempiä. Ehkä nämä vastakkaiset vääristymät suurinpiirtein kumoavat toisensa, mutta varsinaisessa käytössä deduplikoituvuusastetta ei voi etukäteen tietää kuten ei tiedostojen kokoakaan.

Deduplikointia käytettäessä pätee edelleen kolmen käskyn optimointiohje:
– hanki lisää keskusmuistia
– hanki lisää keskusmuistia
– lisää SSD-levy välimuistilaitteeksi