ZFS:n evaluointia – 19. 12. 2011

Tänään arvioin ZFS:n dokumentointia käyttäen esimerkkinä kysymystä: onko deduplikointi järkevää, jos se voi hidastaa levylle kirjoitusta dramaattisesti. Käynnistän testimateriaalin kopioinnin ja huomenna toivottavasti saadaan tieto, kuinka paljon blokkitason deduplikoinnilla tulisi säästöä.

Aikaisemmat päivittäiset lisäykset ZFS:n evaluoinnista olen lisännyt blogikirjoitukseen http://rkoski.vapaavuoro.uusisuomi.fi/kulttuuri/91407-zfsn-evaluointia . Se ei tainnut olla järkevin tapa. Jatkossa joka kerta uusi.

Olen jo aikaisemmin kertonut, että olen tehnyt samantapaista ZFS:n testausta ennenkin. Silloin deduplikoinnin käyttö alkoi hidastaa ZFS:n toimintaa lähes exponentiaalisesti, kun oltiin ylitetty tietty levyn täyttöaste.

Ensin ajattelin kirjoittaa OpenSolarikseen ja erityisesti ZFS:ään liittyvästä dokumentaatiosta. Kehuin jo wikipedian ZFS-artikkelia ( http://en.wikipedia.org/wiki/ZFS#Deduplication ) ja ajattelin, että juuri tuo deduplikoinnin muistivaatimusta koskeva kysymys olisi hyvä pistokoe vertailla dokumentaatiota.

Niinhän se olikin. 310-sivuisessa kirjassa Oracle Solaris Administration: ZFS File Systems ( http://docs.oracle.com/cd/E23824_01/html/821-1448/index.html ) asia kyllä kerrotaan ( http://docs.oracle.com/cd/E23824_01/html/821-1448/gazss.html#gjhav ), mutta melko koukeroisesti eikä anneta selkeää esimerkkiä tai nyrkkisääntöä, kuten wikipedian artikkelissa. Wikipedian artikkelissa deduplikoinnin kohdalla oli myös viitteitä. Seurasin niitä ja ketju Summary: Dedup memory and performance (again, again) ( http://mail.opensolaris.org/pipermail/zfs-discuss/2011-July/049209.html ) zfs-discuss-postituslistalla antaa aika synkän kuvan deduplikoinnin vaikutuksesta suorituskykyyn. Edes runsas keskusmuisti ei riitä ja vaikka sitä olisi, pitää OpenSolariksen ytimen asetuksia muokata debuggerilla. OpenSolariksessa ei ole Linuxin tapaan /proc-tiedostojärjestelmää, jota kautta ytimen asetuksia voi tarkistaa ja muuttaa, joten aika hurjalta tuo näyttää. Ohje sivulla http://mail.opensolaris.org/pipermail/zfs-discuss/2011-May/048244.html ja testinä nykyisen arvon tarkistus:

root@rk6:~# echo ”::arc” | mdb -k | grep meta_limit
arc_meta_limit            =       766 MB

Postituslistojen lukeminen jätti minut lähinnä hämmentyneeksi. SSD-levyn lisääminen cache-laitteeksi auttaisi, samoin ytimen asetusten säätö. Oraclen dokumentaatiosta löytyi kuitenkin tapa lähestyä samaa ongelmaa toiselta suunnalta. Komento:

root@rk6:~# zdb -S tank
Simulated DDT histogram:

bucket              allocated                       referenced         
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
——   ——   —–   —–   —–   ——   —–   —–   —–
  512K        1    128K    128K    128K     640K     80G     80G   79.8G
 Total        1    128K    128K    128K     640K     80G     80G   79.8G

dedup = 655360.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 656943.82

kertoo kuinka paljon tilaa voitaisiin säästää, jos olisi käytetty deduplikointia ja/tai pakkausta ja kuinka paljon tiedoston ylimääräisten kopioiden tallennus sitä lisää. Ylläoleva tulos kertoo huikeasta säästöstä. Kaksi pelkkiä nollia sisältävää 40 Gt kokoista tiedostoa ei veisi juuri yhtään levytilaa, jos deduplikointi olisi käytössä.

Vaikka SSD-levy ei vielä ole saapunut, voin kopioida tiedostot rsync:llä ja simuloida zdb:n avulla, miten paljon tilaa voisi säästää deduplikoinnilla ja pakkauksella. Niitä ei ehkä kannatakaan ottaa käyttöön, jos säästö jää pieneksi. Deduplikoinnista Oraclen dokumentaatio sanoo, että se kannattaa vasta, jos suhdeluku tiedostojen koko jaettuna tarvittavalla tiedostojen koolla on yli 2. Lisäksi on mahdollista käyttää tiedostotason deduplikointia, jolla jo tiedämme saatavan noin 10 % säästön sillä hakemistopuulla, joka on tarkoitus kopioida ZFS:lle. Käynnistetään siis kopionti:

[root@rk7 ~]# time rsync -avH /mirrors /rk6

Se ei kuitenkaan tule valmiiksi tänään. 8 Tt ei siirry gigabitin Ethernetillä hetkessä. Parhaassa tapauksessakin aikaa menee reilu 22 tuntia.

Palataan edellä mainittuun viestiketjuun zfs-discuss-postituslistalla. Myös tiedostojen poistaminen vaikuttaa olevan hidasta ZFS:llä. Ei siitä tällä kertaa enempää kuin hieno ja erikoinen skripti, joka käynnistää jokaiselle poistettavalle tiedostolle oman rm-prosessin. Mitä kaikkea shell-skripteillä voikaan tehdä!

========================
> It seems counter-intuitive – you’d say: concurrent disk access makes
> things only slower – , but it turns out to be true. I’m deleting a
> dozen times faster than before. How completely ridiculous. Thank you 🙂

Well, look at it this way: it is not only about singular disk accesses
(i.e. unlike other FSes, you do not in-place modify a directory entry),
with ZFS COW it is about rewriting a tree of block pointers, with any
new writes going into free (unreferenced ATM) disk blocks anyway.

So by hoarding writes you have a chance to reduce mechanical
IOPS required for your tasks. Until you run out of RAM 😉

Just in case it helps, to quickly fire up removals of the specific
directory
after yet another reboot of the box, and not overwhelm it with hundreds
of thousands queued ”rm”processes either, I made this script as /bin/RM:

===
#!/bin/sh

SLEEP=10
[ x”$1″ != x ] && SLEEP=$1

A=0
# To rm small files: find … -size -10
find /export/OLD/PATH/TO/REMOVE -type f | while read LINE; do
   du -hs ”$LINE”
   rm -f ”$LINE” &
   A=$(($A+1))
   [ ”$A” -ge 100 ] && ( date; while [ `ps -ef | grep -wc rm` -gt 50 ]; do
      echo ”Sleep $SLEEP…”; ps -ef | grep -wc rm ; sleep $SLEEP; ps
-ef | grep -wc rm;
   done
   date ) && A=”`ps -ef | grep -wc rm`”
done ; date
===

Essentially, after firing up 100 ”rm attempts” it waits for the ”rm”
process count to go below 50, then goes on. Sizing may vary
between systems, phase of the moon and computer’s attitude.
Sometimes I had 700 processes stacked and processed quickly.
Sometimes it hung on 50…
========================

Tuo tiedostojen poiston hitaus voisi selittää keväiset ongelmani snapshottien poistossa. OpenSolaris-kone oli kesän kylmänä ja vasta äskettäin kokeilin onnistuuko nyt snapshottien poisto. Ei mitään ongelmaa.

Palataan dokumentoinnin arviointiin. Sivulla http://docs.oracle.com/cd/E23824_01/html/821-1448/gaypw.html#gfxtd on lause ”Cache devices cannot be mirrored or be part of a RAID-Z configuration.”, jonka voisi tulkita niin, että raidz-pooliin ei voi lisätä cache-laitetta. http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#… kuitenkin rauhoittaa: ”it is not possible to mirror or use raidz on cache devices, nor is it necessary. If a cache device fails, the data will simply be read from the main pool storage devices instead.”

Minun mielestäni wikipedian ZFS-sivu on paras. Se on melko lyhyt, mutta se kertoo olennaisen selkeästi. Sivustolla http://www.solarisinternals.com/wiki/index.php/Solaris_Internals_and_Per… on useita wiki-tyyppisiä ZFS:ää käsitteleviä oppaita. Minun tuntumani on, että sekin olisi parempi kuin Oraclen oma dokumentointi. Syvällisintä tietoa löytyy kuitenkin Oraclen työntekijöiden blogeista, kuten http://blogs.oracle.com/roch/entry/dedup_performance_considerations1 .