ZFS deduplikace a spotřeba paměti

[Radek]

Ahoj,

momentalne kupujeme od Oracle ZS5-2. Interne to bezi na solarisu a pouziva to ZFS. Durazne jsem zadal ze nechceme deduplikaci. Technik me ujistil ze zatim nikdo nechtel od nich zapnout deduplikaci a ani to standarnet nenabizeji. Cena(RAM) za deduplikaci je strasne vysoka. Podle meho osobniho nazoru se jedna o nejhorsi vlastnost ZFS a ja bych si ji niky nezapnul.

Naopak komprese je velmi uzitecna vlastnost. Na maildir bych ji urcite zapnul. ZSF dokonce umi, pokud se nepletu, "chytrou" kompresi. Nejprve zkomprimuje prvni blok a pokud je kompresni pomer spatnej, dale nekomprimuje. Pokud je dobrej, zkomprimuje celej soubor.

Radek

[Reklama]

[hugochavez]

@Pavko
"Pro mě je deduplikace nepoužitelná, když na 500 GB dat nestačí ani 24 GB RAM"

pokud se to chova takhle tak tam mas neco zatracene spatne.
Obecne se doporucuje:

"If you plan to use ZFS deduplication, ensure you have at least 5 GB RAM per TB of storage to be deduplicated."

viz http://doc.freenas.org/9.3/freenas_intro.html#ram

dale "The recommended minimum (mysleno pro FreeNAS system) is 8 GB of RAM" viz URL vyse.

Myslim ze by sis mel pozorne procist tenhle manual co napsali primo vyvojari co delaj FreeNAS/ZFS abys nemarnil cas zbytecnymi experimenty......

Taky je dobry si procist tohle https://forum.root.cz/index.php?topic=12850.60   vlakno kde zdejsi pleenum ZFS/dedup probiralo  )

Pokud te ZFS problematika zajima vic skoukni tohle video:

 http://www.jupiterbroadcasting.com/116766/for-the-love-of-zfs-bsd-now-203/   

Krome exkursu do historie ZFS tam probiraj prave i DEDUP a posledni napady ohledne jeho vylepseni, napr Intel chce rozhazovat files podle typu a vhodnosti na komprimaci/dedup na ruzny datasety, dale "zastropovani" velikosti DDT (=DeDuplicatinTable) ci jeji prehozeni na NVMe
 https://en.wikipedia.org/wiki/NVM_Express
ktery se rychlosti priblizuje RAM ale cenove/kapacitne je stravitelnejsi, indexovani "pozmenenych bloku", megabloky atd atd

Vsechny dily tohodle podcastu se v podstate nezabyvaj nicim jinym nez problematiku *BSD a ZFS:
http://www.jupiterbroadcasting.com/show/bsdnow/page/2/

@trubicoid2
"podle vypoctu oraklu staci numirovi 0.5GB ram na deduplikaci"

Nejsem si vubec jistej jestli vypocty pro Oracle system maj nejakou relevanci pro openZFS....?

ZFS u obou sice vychazi ze stejnyho zakladu od Sun, ale uz davno se rozdelil a podle openZFS devs je pres polovina kodu uz jina nez u Oraclu, dukazem ceho budiz ze Oracle zatim neodtahl lidi z iXSystems k soudu prestoze urcite diky open source povaze ZFS kodu z dilny iXSystems je soudruzi od Oraclu pravidelne procitaji...... uz jen pro "inspiraci" ohledne novych napadu ;o)

@LolPhirae
RE: dedup--"Nic. Je to prostě nepoužitelné na normálním hardwaru."

Ano- to je spravna odpoved!  ))))  https://www.youtube.com/watch?v=QEsVL9Lr80k#t=6m1s

Dedup ale je myslen spise jako enterprise feature (i kdyz i tam to drhne) pro servery ktery u iXsystems davaj dohromady a ktery maj >128GB RAM.....

@Miroslav Silhavy
"Jako minimum vůbec pro ZFS se doporučují 4 GB RAM + 1 GB na každý 1 TB dat."

To je SPATNA ODPOVED - viz vyse  ;o)

@KIt
"Možná by se dnes pro tento účel hodil spíše BtrFS."

Ne nehodil- BtrS rozhodne neni "production ready" a lidi co diky nemu prisli o data by to povrdili.
Naproti tomu uzivatele ZFS -pokud si vlastni blbosti pod sebou nepodrizli vetev- pouzivaj ZFS uz roky bez problemu =
jsem 1 z nich.

@MS
"....vyzkoušet různé typy kompresí (zfs set compression=), bude to určitě účinnější, než deduplikace"

Ano to je spravna odpoved viz:
Unless you have a lot of RAM and a lot of duplicate data, do not change the default deduplication setting of “Off”. For performance reasons, consider using compression rather than turning this option on.

http://doc.freenas.org/9.3/freenas_storage.html?highlight=deduplication#deduplication

https://constantin.glez.de/2011/07/27/zfs-to-dedupe-or-not-dedupe/

@Y.
"...Pravdepodobne nechape, co ta deduplikace dela..."
Mas to skoro na jednicku, jen bych dodal ze pri zapisu se pocitaji i hashe samotnych hashu a ty se pak rozhazuji ve Vdev tak aby i ztrata 1 az 3 disku na ne nemela vliv..... (RaidZ1-RaidZ3)

Komprimace textu je velmi vyhodna, komprimace hodne zkomprimovanych napr.MP3 ci videa je prakticky nemozna, takze je rozumne tyto typy drzet na vlastnim datasetu BEZ komprimace.

Jinak opakem dedup je "klonovani" alias rekneme ZFS systemu aby STEJNA data pri zapisu nakopiroval i jinam a to podle algoritmu ktery zaruci ze "totozny zlomek souboru" NEBUDE na stejnem disku.............coz uz je docela voodoo  )))

@Sten
"ZFS se (jako všechny checksumované filesystémy) opravuje samo, když narazí na chybu. Zkontrolovat (a opravit) všechny soubory lze pomocí scrubu. Pokud narazí na chybu, kterou opravit nedokáže, tak opravit nejde."

V principu to vypada nejak takhle https://derivadow.files.wordpress.com/2007/01/zfs-self-healing.jpg?w=620
Scrub se pak v podstate tvari jako ze chce cist vsechno naraz a projizdi cely Vdev.......coz muze zabrat i nekolik hodin nicmene to funguje VELMI SPOLEHLIVE! = vlastni zkusenost.

Vice o scrub+self-healing system zde:
http://doc.freenas.org/9.3/zfsprimer.html?highlight=scrub#zfs-primer

[hugochavez]

@Radek
"momentalne kupujeme od Oracle ZS5-2. Interne to bezi na solarisu a pouziva to ZFS.... Technik me ujistil ze zatim nikdo nechtel od nich zapnout deduplikaci"

Az budes priste mluvit s tim technikem zeptej se ho schvalne nakolik je mozny namountovat ZFSpool vytvoreny na FreeNASu (alias openZFS) na jejich Oracle....?
Docela by me zajimalo jestli tam je vubec nejaka kompatibilita.....
THX

[Miroslav Šilhavý]

Nemohu souhlasit, že je to nepoužitelné. FreeNAS a jeho tabulku nároků na deduplikaci čtu poprvé, ale nesedí to proti ostatním informacím, které jsem kde četl, ani proti výpočtu Oraclu. Je možné, že FreeNAS používá menší blok než 128 KiB.. (? ví někdo, já na žádném FreeNASU nemám ZFS).

Deduplikaci používám např. na storage záloh fotografií, kde mi vůbec nevadí nižší rychlost, protože data tam stejně lezou pomalu rsyncem. Dokonce mám méně paměti, než je doporučení, a i tak to stačí. Ale je taky pravda, že se mi to vyplatí - deduplikační poměr mám > 2:1.

Pak ještě pouštím deduplikaci jen nad datasety jailů FreeBSD, tam se provádí zápis jen jednou při updatu systému / jailů, takže ke zpomalení dojde jen v ten okamžik, za běhu už pak ne (vše ostatní se zapisuje do /home, /usr/local a /var, které dedup mají zakázaný).

Na produkci, na proměnlivá data běžného serveru, to asi opravdu k ničemu není.

[Pavko]

FreeNAS implicitně používá velikost bloku 128k, ale lze změnit.
Mezitím jsem vyzkoušel ZFS (ještě s dedup on) pro jinou strukturu dat a tam to celkem rychlostně je celkem dobré. Zatím jsem zjistil, že rychlostní problém dělá velké množství malých souborů.

Děkuji všem, hlavně hugochavez-ovi, budu se dál učit.

[Reklama]

[Kit]

Deduplikaci používám např. na storage záloh fotografií, kde mi vůbec nevadí nižší rychlost, protože data tam stejně lezou pomalu rsyncem. Dokonce mám méně paměti, než je doporučení, a i tak to stačí. Ale je taky pravda, že se mi to vyplatí - deduplikační poměr mám > 2:1.

To je také správné použití deduplikace. Z podobných důvodů ji používám na jednom ze serverů, kde se schází opravdu velké množství totožných souborů od různých uživatelů.

[hugochavez]

...... kde se schází opravdu velké množství totožných souborů od různých uživatelů.

Coz je duvodem proc expertem na deduplikaci jsou napr. soudruzi z Dropboxu, tam to ma pomerne zasadni alias $ vyznam 

Bohuzel jsou rovnez experti i na hashovani obsahu uzivatelu a "nevhodny" obsah bez pardonu a varovani mazou.....
Coz ovsem BFU ktery neni uplne padly na hlavu dokaze obejit tak ze napr. film o par sekund zkrati ci MP3 prekomprimuje 

Takze "cat and mouse game" vesele pokracuje.....

[TomasMarny]

Ještě jsem nenarazil na situaci, kdy by mi deduplikace nějak výrazně pomohla a to i v situacích zdánlivě ideálních (.vmdk soubory mnoha v zásadě identických virtuálek). S paměti jsem ovšem nikdy problém neměl, už jsem totiž pochopil, že pro ZFS je hodně paměti prostě třeba takže všude cpu 256GB (chystám se nasadit EPYC a tam půjde už 512GB) s tím, že velikost ARC limituju na 180GB.

arc_summary

------------------------------------------------------------------------
ZFS Subsystem Report                            Fri Dec 01 11:23:06 2017
ARC Summary: (HEALTHY)
        Memory Throttle Count:                  0

ARC Misc:
        Deleted:                                5.29m
        Mutex Misses:                           266
        Evict Skips:                            266

ARC Size:                               100.00% 180.00  GiB
        Target Size: (Adaptive)         100.00% 180.00  GiB
        Min Size (Hard Limit):          83.33%  150.00  GiB
        Max Size (High Water):          1:1     180.00  GiB

ARC Size Breakdown:
        Recently Used Cache Size:       40.73%  73.31   GiB
        Frequently Used Cache Size:     59.27%  106.69  GiB

ARC Hash Breakdown:
        Elements Max:                           3.81m
        Elements Current:               95.56%  3.64m
        Collisions:                             2.17m
        Chain Max:                              4
        Chains:                                 181.10k

ARC Total accesses:                                     125.26m
        Cache Hit Ratio:                94.89%  118.86m
        Cache Miss Ratio:               5.11%   6.40m
        Actual Hit Ratio:               91.49%  114.61m

        Data Demand Efficiency:         99.86%  100.99m
        Data Prefetch Efficiency:       44.54%  7.36m

        CACHE HITS BY CACHE LIST:
          Anonymously Used:             3.00%   3.57m
          Most Recently Used:           7.37%   8.77m
          Most Frequently Used:         89.05%  105.84m
          Most Recently Used Ghost:     0.23%   277.31k
          Most Frequently Used Ghost:   0.35%   410.63k

        CACHE HITS BY DATA TYPE:
          Demand Data:                  84.85%  100.85m
          Prefetch Data:                2.76%   3.28m
          Demand Metadata:              9.21%   10.95m
          Prefetch Metadata:            3.18%   3.78m

        CACHE MISSES BY DATA TYPE:
          Demand Data:                  2.17%   139.02k
          Prefetch Data:                63.78%  4.08m
          Demand Metadata:              17.10%  1.10m
          Prefetch Metadata:            16.95%  1.09m


File-Level Prefetch: (HEALTHY)
DMU Efficiency:                                 144.76m
        Hit Ratio:                      70.88%  102.60m
        Miss Ratio:                     29.12%  42.15m

        Colinear:                               42.15m
          Hit Ratio:                    0.01%   2.45k
          Miss Ratio:                   99.99%  42.15m

        Stride:                                 95.55m
          Hit Ratio:                    100.00% 95.55m
          Miss Ratio:                   0.00%   2.25k

DMU Misc:
        Reclaim:                                42.15m
          Successes:                    0.18%   75.01k
          Failures:                     99.82%  42.08m

        Streams:                                7.05m
          +Resets:                      0.00%   253
          -Resets:                      100.00% 7.05m
          Bogus:                                0

[Miroslav Šilhavý]

Ještě jsem nenarazil na situaci, kdy by mi deduplikace nějak výrazně pomohla a to i v situacích zdánlivě ideálních (.vmdk soubory mnoha v zásadě identických virtuálek). S paměti jsem ovšem nikdy problém neměl, už jsem totiž pochopil, že pro ZFS je hodně paměti prostě třeba takže všude cpu 256GB (chystám se nasadit EPYC a tam půjde už 512GB) s tím, že velikost ARC limituju na 180GB.

Myslím, že na takové použití je ZFS zbytečné úplně.
Dedkuplikaci na vmdk bych stopro vůbec nepouštěl, to je absolutní zabiják výkonu.
Má to smysl nad běžnými soubory, tj. buďto uvnitř vmdk, nebo třeba přes NFS.

[TomasMarny]

Myslím, že na takové použití je ZFS zbytečné úplně.
Dedkuplikaci na vmdk bych stopro vůbec nepouštěl, to je absolutní zabiják výkonu.
Má to smysl nad běžnými soubory, tj. buďto uvnitř vmdk, nebo třeba přes NFS.

Pokud se deduplikační tabulka vejde do paměti tak je propad výkonu minimální. Ověřeno testy v praxi. Nicméně deduplikaci vzhledem k nepřesvědčivým výsledkům nepoužívám. ZFS tam mám kvůli snapshotům (včetně send/receive) a kvůli kontrolním součtům (jak naprd je běžný RAID10 bez kontrolních součtů jsem se bolestivě přesvědčil na vlastní kůži).

[Ivan Večeřa]

Ono opravdu zalezi na use-case. Zapinat deduplikaci by default nebo pool-wide je nesmysl a zbytecne plytvani pameti. Sam mi s uspechem pouzivam u ZVOLu, ktere slouzi jako uloziste exportovane pres iSCSI bezdiskovym stanicim. Na stanicich bezi Windows 7 a dedup ratio je celkem velke cca 3.5:1.

Je ale potreba dat bacha na parametry, treba ja u tech ZVOLu mam volblocksize 32k a velikost clusteru v tech Windows je tez 32k. Pri tomto nastaveni ma DDT tabulka 3505973 polozek a kazda z nich zabira v pameti 194 bajtu - tzn. nejakych 648MB. Pokud bych ovsem volblocksize nechal na 4k a stejne tak NTFS cluster size tak tech polozek bude 8x vice a spotreba pameti pro DDT pak vice nez 5 GB, coz uz je znatelne.

Takze za mne, deduplikaci ano, ale s _velkym_ rozmyslem a hlavne tam kde to ma smysl. U mail serveru to smysl nema protoze i stejne zpravy se na zacatku budou lisit hlavickami, takze ty bloky budou jine.

Dale je dobre dat na datasety nebo ZVOLy checksum vhodnou pro deduplikaci (napr. SHA256), jinak bude dochazet ke kolizim a celoblokovym porovnanim, coz se odrazi na vykonu.