ZFS és tömörítés
2009.07.11. 21:34
Ha valamiért úgy gondolnánk, hogy a ZFS nem elég lassú, könnyen segíthetünk a dolgon: kapcsoljuk be a tömörítést!
A fájlrendszer-tömörítésnek mindig is voltak támogatói és ellenzői is. Egy biztos: sosem volt annyi lóerő a gépeinkben, mint ma, és nevetséges az a teljesítmény, amit a mostani gépünk nyújt ahhoz képest, amit két év múlva fogunk használni.
Erő tehát van a digitális abakuszunkban, és évről-évre egyre több. Ez sajnos nem mondható el a diszkekről, amelyek bár kellemesen híznak (idén 2 TB-nál tartunk, két év múlva valószínűleg megint duplázunk), viszont a mérettel együtt az IOPS-nek nevezett paraméter, amely a diszkek tranzakcionális sebességét (amely a pozicionálási időkből -seek time- ered) mutatja, csak nem akar nőni.
Vannak 7200, 10000 és 15000-es fordulatszámon járó diszkjeink, és az átlagos seek time-ra már 2 ms-ot sem szégyellnek írni a gyártók, de ha a CPU-k sebességével mérjünk a diszkjeinket, már rég 1728000-as fordulatszámon kellene pörögniük, és 20-40 mikroszekundum alatt kellene válaszolniuk.
Szóval a teljesítménymérleg nyelve erősen eltolódott a diszkek felől a processzorok felé, így hát a tömörítés támogatói az mondják: miért ne használjuk az unatkozó CPU-(ka)t az adatok méretének csökkentésére, és így a lassú diszkek sebességének növelésére?
Logikus.
Próbáljuk ki. Van itt egy gép nyolc erős CPU maggal, meg egy rakás diszkkel. Másoljunk a diszkekre tömörítéssel, és még jobb tömörítéssel.
A ZFS jelenleg az LZJB-t (a ZFS (egyik) szerzőjének, Jeff Bonwicknek az LZ-like tömörítési algoritmusa, amely meglehetősen gyors) és a gzipet támogatja. Előbbi kevésbé tömörít, utóbbi jobban, de lassabban. Mennyivel? Ennyivel:
A CPU-terhelési grafikonon látható alacsonyabb kernelidő (zöld, 300% körül, azaz a nyolc magból kb. 3-at használt a kernel) az LZJB-re, míg a hirtelen ugrás utáni kb. 500% (azaz 5 mag) a gzip (default, azaz -6).
Mellette a hozzá tartozó hálózati forgalom, azaz LZJB-vel kb. 6-700 Mibps-t tudott benyelni a gép (több szálon történő rsynces másolással), míg gzippel csak kb. 450-et.
Ezt kb. be is hozza a tömörítésben, lzjb-vel a compressratio kb. 1,14x, míg gzippel 1,5 feletti.
Fontos megjegyezni, hogy a betömörítés és a kitömörítés nem (feltétlenül) szimmetrikus, azaz olvasásnál más lesz (vagy legalábbis lehet) a kép.
De ez messze nem tudományos igényű mérés, csak egy gyors ténymegállapítás. :)
Szerző: blackshepherd
Szólj hozzá!
Címkék: performance cpu kernel system usage compression gzip zfs lzjb
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.