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.

Tömörítés típusa Hatékonyság - az eredeti hány %-a a tömörített? Betömörítés ideje [s] Kitömörítés ideje [s]
lzjb 83% 11 13
gzip -1 kernel: 56%
user: 54%
kernel: 23
user: 49
kernel: 16
user: 16
gzip -2 kernel: 55%
user: 53%
kernel: 23
user: 49
kernel: 16
user: 16
gzip -3 kernel: 55%
user: 53%
kernel: 23
user: 50
kernel: 16
user: 16
gzip -4 kernel: 54%
user: 52%
kernel: 24
user: 60
kernel: 16
user: 17
gzip -5 kernel: 54%
user: 51%
kernel: 24
user: 63
kernel: 16
user: 17
gzip -6 kernel: 53%
user: 51%
kernel: 24
user: 69
kernel: 16
user: 15
gzip -7 kernel: 53%
user: 51%
kernel: 25
user: 73
kernel: 16
user: 17
gzip -8 kernel: 53%
user: 51%
kernel: 27
user: 89
kernel: 16
user: 15
gzip -9 kernel: 53%
user: 51%
kernel: 30
user: 122
kernel: 16
user: 16
bzip2 -1 51% 168 67
bzip2 -2 50% 170 67
bzip2 -3 50% 175 66
bzip2 -4 50% 180 67
bzip2 -5 50% 185 68
bzip2 -6 50% 185 69
bzip2 -7 50% 187 70
bzip2 -8 49% 189 72
bzip2 -9 49% 192 77

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:

https://suckit.blog.hu/api/trackback/id/tr571842163

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.

hulyeinformatikus 2010.05.21. 08:48:31

Köszi az írást.

"képes felismerni, hogy azok tömörítettek (gzip, bzip2),"

Hogy kerülnek tömörítésre a maildir/mailbox-ok?

hulyeinformatikus 2010.05.22. 23:58:26

@blackshepherd: Köszi, tehát olvasni tudja.
Hogy kerül tömörítésre a tartalom egy aktív mailbox-nál?

blackshepherd · http://suckit.blog.hu 2010.05.24. 21:33:05

@hulyeinformatikus: Ja, hogy ez érdekel. find . -type f -atime +30d | xargs gzip
Például így.
De mintha az újabb MDA-ja már érkezéskor is tudná tömöríteni.
süti beállítások módosítása