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. :)

A bejegyzés trackback címe:

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

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.

Nincsenek hozzászólások.
süti beállítások módosítása