ZFS deduplikace a spotřeba paměti

[Pavko]

Zdravím. Chtěl bych se zeptat s Vaší zkušeností se souborovým systémem ZFS (vždy dedup on). Chtěl bych ho nasadit na svazek s maildiry. Udělal jsem dost testů a jsem z nich - se zapnutou deduplikací, celkem nepříjemně, rozčarován. Nejdřív jsem na prvním stroji udělal 500GB svazek, 8GB RAM. Po zaplnění cca 70GB rychlost 300-500kB - nepoužitelné. Tak jsem vzal jiný stroj 2x CPU, 24GB ECC RAM, 1TB svazek, a po zaplnění cca 500GB crash systému. Zkoušel jsem i jiný stroj s FreeNAS a tam během kopírování dat svazek úplně lehnul. HW je ověřený, značkový. Máte nějakou zkušenost se ZFS a případně jakou? Vše bylo se zapnutou deduplikací, zkoušel jsem i různé velikosti bloků, distribuce Debian, FreeBSD. Netušíte co dělám špatně?

[Reklama]

[trubicoid2]

zkusenosti mam podobne, dedup potrebuje spoustu RAM, nekde jde najit vypocet kolik, ale je to moc

mi to fungovalo pomalu a pak to dokonce tuhlo, ani to neslo rozduplikovat, bylo potreba docasne pripojit SSD jako ARC a docasne zvetsit RAM

zaver - deduplikaci ne

[Pavko]

Díky za informaci. Zkusím testy bez deduplikace, pouze s kompresí. Pro mě je deduplikace nepoužitelná, když na 500 GB dat nestačí ani 24 GB RAM. Nezkoušel jste s SSD připojený trvale? Přece jenom se na SSD vejde více než do RAM.
Zkusil jsem simulaci násilného vypnutí stroje během usilovného zápisu na ZFS a poté rekonstrukce trvala (při dedup on) cca 70 GB dat cca 5 hodin. Sice se to povedlo, ale ten čas.

[trubicoid2]

SSD jsem tam chvili mel, ale pomale to bylo stejne
jediny kladny vliv to melo, ze se mi podarilo data odduplikovate bez vytuhnuti

vypocet potrebne pameti je tu: http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html

[Numira]

Virtuální stroj pod ESX, 2 CPU, 4GB RAM, data nextcloudu ve vlastnim poolu ...

ZFS mám jen na data, OS běží z EXT4. Z ext4 občas na ZFS přemigruju konkrétní adresáře, typicky /var/log/, /var/lib/mysql/ apod ...

V tuto chvíli cca do 20 strojů, b2hem dvou let žádná ztracená data, žádné výkonnostní problémy/excesy ...

Vše na debianu od deb 7 ...

zpool status -D datapool
  pool: datapool
 state: ONLINE
  scan: none requested
config:

        NAME                                    STATE     READ WRITE CKSUM
        datapool                                ONLINE       0     0     0
          f37a2fb8-f9aa-4671-9ff4-d5df4a83a5d2  ONLINE       0     0     0

errors: No known data errors

 dedup: DDT entries 1494947, size 291 on disk, 157 in core

bucket              allocated                       referenced         
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    1.08M    136G    136G    136G    1.08M    136G    136G    136G
     2     278K   34.5G   34.5G   34.5G     645K   80.2G   80.2G   80.2G
     4    68.4K   8.54G   8.54G   8.54G     275K   34.4G   34.4G   34.4G
     8      279   32.8M   32.8M   32.8M    2.53K    300M    300M    300M
    16       45   5.01M   5.01M   5.01M      870   98.1M   98.1M   98.1M
    32      118   14.3M   14.3M   14.3M    5.76K    718M    718M    718M
    64      350   43.5M   43.5M   43.5M    40.5K   5.04G   5.04G   5.04G
   128       20   2.50M   2.50M   2.50M    3.62K    464M    464M    464M
   256    2.94K    376M    376M    376M    1.05M    135G    135G    135G
  128K        1    128K    128K    128K     200K   25.0G   25.0G   25.0G
 Total    1.43M    179G    179G    179G    3.28M    417G    417G    417G

[Reklama]

[Pavko]

OK. Kolik tam máte dat?

[trubicoid2]

podle vypoctu oraklu staci numirovi 0.5GB ram na deduplikaci

ja mel bloku radove vic a daleko mensi duplikaci

[Lol Phirae]

Netušíte co dělám špatně?

Nic. Je to prostě nepoužitelné na normálním hardwaru.

[Miroslav Šilhavý]

První, co je pro deduplikaci potřeba, je mít hash bloku dat. Zkuste změnit nastavení na skein,verify - je to rychlejší, terpve při kolizi porovná data fyzicky. Jde o to, jak moc deduplikovatelná vůbec jsou.

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

[Numira]

OK. Kolik tam máte dat?

Poslední řádek
Total    1.43M    179G    179G    179G    3.28M    417G    417G    417G

Takže referenced: 417G dat, fyzicky uložených na 179G (allocated)

[trubicoid2]

...Zkuste změnit nastavení na skein,verify - je to rychlejší, terpve při kolizi porovná data fyzicky...

aha, zajimave, to tenkrat nebylo

co jeste te nrychlejsi Edon-R?

[Miroslav Šilhavý]

co jeste te nrychlejsi Edon-R?

Nezkoušel jsem, ani jsem nestudoval. Jen jsem chtěl naznačit cestu. Znám to taky jen na FreeBSD.
Patrně by chtělo změnit ještě zfs set checksum=skein, ale opět, hlouběji jsem nezkoumal.
Deduplikaci mám jen na jednom datasetu, a tam je mi zrovna výkon jedno .

[j]

....Netušíte co dělám špatně?

Spatne nedelas nic. ...Tuhle mas vypocet http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html

Abys to nemusel cist, tak je to pocet bloku x 320. Tzn na 130GB disku kterej ma kilovy bloky potrebujes pri 129059324 blocich x 320 = 38GB RAM. Pocitaj teda s alokovanejma blokama, ja prozmenu s plnym diskem.

Na terovej disk s 4k blokama bys tudiz potreboval zhruba 80GB RAM

Takze viz Lol Phirae - je to zcela nepouzitelny na zcela libovolnym HW.

[Miroslav Šilhavý]

Na terovej disk s 4k blokama bys tudiz potreboval zhruba 80GB RAM

Takze viz Lol Phirae - je to zcela nepouzitelny na zcela libovolnym HW.

Abychom se zde nedopouštěli ještě hlubších chyb, tak výchozí recordsize je na ZFS 128 KiB.
1 TB disk (10^12) / 128 KiB (2^17)  = 7 629 394 recordů

Pokud by byla deduplikace nulová, pak by pro 1 TB disk bylo potřeba 7 629 394 × 320 B = 2,27 GiB.
V estimacích se pracuje s tím, že nemá smysl používat deduplikaci pod cílový poměr 1:2, proto se uvádí, že na každý 1 TB dat je potřeba cca 1 GiB RAM. Pokud jsou data deuplikovatelná v lepším poměru, bude spotřeba RAM nižší. Pokud jsou naopak deduplikovatelná v horším poměru, tak nejhorší poměr je 2,27 GiB / 1 TB disku při nulové deduplikaci (poměr 1:1).

Na živých datech můžete simulovat efekt deduplikace pomocí příkazu zdb -S jmeno_poolu a posoudit, jestli se vyplatí.

Záměrně používám pro disky desítkovou základnu, protože výrobci disků uvádějí 1 TB = 10^12 B, zatímco výrobci RAM jako 2^x.

Zdroje:
http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html
https://www.freebsd.org/cgi/man.cgi?query=zdb&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html

[Kit]

....Netušíte co dělám špatně?

Spatne nedelas nic. ...Tuhle mas vypocet http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html

Abys to nemusel cist, tak je to pocet bloku x 320. Tzn na 130GB disku kterej ma kilovy bloky potrebujes pri 129059324 blocich x 320 = 38GB RAM. Pocitaj teda s alokovanejma blokama, ja prozmenu s plnym diskem.

Na terovej disk s 4k blokama bys tudiz potreboval zhruba 80GB RAM

Defaultně se používají bloky 128 KB, takže to zas taková hrůza není.