Szombaton arra a kínzó, gyötrelmes kérdésre ébredtem, hogy mit választanék, ha lenne mondjuk egy PiB-nyi e-mailem, de mégis annyira elmaradott lennék, hogy azokat nem valami speciális adattárban, hanem hagyományos fájlrendszerben tartom. A fájlokat tömöríteném, egyesével, vagy a fájlrendszert (és a fájlrendszer alatt itt most a ZFS-t értem, azon most ne akadjunk ki, hogy valószínűtlen, hogy bárki, aki egy PiB-nyi levelet tárol, ZFS-t használjon)?

Mindkettőnek megvannak az előnyei. Ha a fájlokat külön tárolom, a gyorsan pörgő leveleket tömörítetlenül hagyhatom, míg a pár naposakat valami egyszerű, gyors algoritmussal, a több hónaposakat pedig valami kemény, Amperzabálóval nyomorgathatom.
A fájlrendszer előnyét pedig azt hiszem mondani sem kell: bekapcsolom, és elfelejtem, pontosabban gúvadó szemekkel skubizom a terhelési görbéket, nehogy hamarabb fogyjon el a CPU, mint a rendelkezésre álló tárhely.

A probléma tehát, hogy ha a leveleimet mondjuk Dovecottal, maildirben tárolom, amely képes felismerni, hogy azok tömörítettek (gzip, bzip2), érdemes inkább ezt használni, vagy célszerűbb inkább bekapcsolni a zfs-ben a tömörítést?

A teszt kedvéért fogtam pár üzleti levelet (azaz bőven vannak bennük excelek, meg wordök), és összenyomtam őket így is, meg úgy is. 24 ezer e-mailről van szó, összesen 1 GiB méretben. Az adatok memóriadiszken voltak mindvégig.

A kernel nevű számok a ZFS-sel tömörített, míg a user a gzippel tömörített esetet jelentik. lzjb csak a ZFS-ben van, a bzip2 pedig csak userspace-ben.

Mit lehet megállapítani? Először is azt, hogy az lzjb gyors, cserébe nem tömörít valami jól, az eredeti méret csupán 83%-ára tudta összepréselni az e-mailjeimet.
Hozzá képest a gzip, még a leggyorsabb módban (-1) is egy vánszorgó csiga, mert hiába nyomja össze a leveleket majdnem a felére (azaz kb. 1,8-szor annyi helyet tudunk használni, mint amekkora merevlemezt veszünk), ezt több, mint kétszer olyan lassan éri el, mint az lzjb.

Az első érdekesség itt látszik: a ZFS gzip -1-e és a fájlok egyesével történő becsomagolása közt két százalékpontnyi különbség van. Ennek egy lehetséges oka az, hogy a gzip program egész leveleket kap, míg a ZFS a 128 KiB-os rekordjait tömöríti.
A másik érdekesség a tömörítés ideje, amelyben a ZFS és a userspace-ben futó gzip között több, mint kétszeres eltérés van, a ZFS javára. Ennek feltételezett oka az, hogy a userspace-ben futó tömörítést szekvenciálisan végeztem, azaz egy gzip program ment végig mind a 24 ezer fájlon, sorban. A kernelben futó ZFS viszont nem akkor tömörít, amikor megkapja az adatokat, hanem ráér a munkát elvégezni később, a diszkhez "közelebb", hiszen szuboptimális lenne egy gyorsan változó fájl blokkjait egymilliószor betömöríteni, mikor diszkre csak egyszer kerül ki. Ez önmagában még nem magyarázza a dolgot, hiszen ha a kernelben futó gzip -1 implementáció megegyezik a userspace-ben futóval, annak nem szabadna kétszer olyan gyorsnak lennie.
A drasztikus eltérés okaként én így a ZFS-ben megvalósított párhuzamosítást képzelném, hiszen össze tud gyűlni a pufferekben sok adat, és amikor eljön a tömörítés ideje, az ott lévő blokkok párhuzamosan tömöríthetők (a gépben 8 CPU mag volt). Read the source Luke, de ehhez most lusta vagyok.
Az elképzelést mindenesetre alátámasztani látszik a kitömörítés, hiszen ott a user és kernel megvalósítás közt alig van különbség. Ennek oka a fenti elmélet szerint pedig az, hogy olvasáskor nem lehet párhuzamosítani, hiszen a cp egy szálon tölti be az adatot (nos, a prefetch ezen azért változtathatna, de ezek elég kis fájlok ehhez).

Az igazán durva értékek a gzip -9 felé haladva kezdenek kialakulni, 122 másodpercet várni 1 GiB betömörítésére azért kemény dolog. A ZFS-es 30 másodperc itt ennek fényében világbajnoknak tűnhet, de vegyük hozzá, hogy ezalatt a 30 másodperc alatt a gép annyira beáll, hogy az ssh konzolon sem lehet gépelni...

A bzip2-re túl sok szót nem is pazarolnék, a bzip2 -1-et hívhatnánk akár gzip -10-nek, a -9-et pedig -19-nek, olyan szépen folytatja a gzip által megkezdett időket (nos, kivéve a kitömörítést, abban ugyanis egy bazi nagy ugrás van).

Összességében az látszik, hogy a gzip -1-hez képest 5%-ot nyerhetünk a tömörítésben, de cserébe négyszer annyit kell az eredményre várni, ami nagyon ritkán érheti meg.

A fentiek alapján azt gondolom tehát, hogy ha 1 PiB-nyi levelem lenne, és ezekben (csak a saját levelezésemből kiindulva) be tudnék azonosítani három jelentős réteget, azaz:

1. a nagyon gyorsan pörgő levelek
2. a gyakran használt levelek
3. a szinte sosem használt levelek

akkor érdemes lenne megfontolni ezek sávos tömörítését. Az elsőét lzjb-vel (vagy semmivel, bár az lzjb-be érdemes beleszámolni, hogy a diszkekre eső IOPS-igényt hatékonyan cserélhetjük be vele CPU idő-igényre), a másodikét gzip -1-gyel, a harmadikét pedig gzip -9-cel.
A ZFS és a userspace tömörítés közti konstans 2-3%-nyi különbség miatt pedig ekkora méretekben már megérné a userspace tömörítést választani, amellyel ráadásul hatékonyabban is lehet szabályozni annak erősségét.

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.