Jak duży jest obecnie mój stół deduplikacyjny ZFS?

21

Przeczytałem wiele informacji na temat planowania wymagań pamięci RAM dla deduplikacji ZFS. Właśnie zaktualizowałem pamięć RAM mojego serwera plików, aby obsługiwać niektóre bardzo ograniczone deduplikacje na Zvols ZFS, na których nie mogę używać migawek i klonów (ponieważ są one zvols sformatowane jako inny system plików), ale będą zawierały dużo zduplikowanych danych.

Chcę się upewnić, że nowa pamięć RAM, którą dodałem, będzie obsługiwać ograniczoną deduplikację, którą zamierzam robić. W planowaniu moje liczby wyglądają dobrze, ale chcę mieć pewność .

Jak mogę sprawdzić aktualny rozmiar tabel deduplikacji ZFS (DDT) w moim systemie na żywo? Czytam ten wątek z listy mailingowej, ale nie jestem pewien, w jaki sposób docierają do tych liczb. (W zdb tankrazie potrzeby mogę opublikować wyniki , ale szukam ogólnej odpowiedzi, która może pomóc innym)

Josh
źródło

Odpowiedzi:

17

Możesz użyć zpool status -D poolnamepolecenia.

Dane wyjściowe wyglądałyby podobnie do:

root@san1:/volumes# zpool status -D vol1
  pool: vol1
 state: ONLINE
 scan: scrub repaired 0 in 4h38m with 0 errors on Sun Mar 24 13:16:12 2013

DDT entries 2459286, size 481 on disk, 392 in core

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    2.23M   35.6G   19.0G   19.0G    2.23M   35.6G   19.0G   19.0G
     2     112K   1.75G   1005M   1005M     240K   3.75G   2.09G   2.09G
     4    8.03K    129M   73.8M   73.8M    35.4K    566M    324M    324M
     8      434   6.78M   3.16M   3.16M    4.61K   73.8M   35.4M   35.4M
    16      119   1.86M    811K    811K    2.33K   37.3M   15.3M   15.3M
    32       24    384K   34.5K   34.5K    1.13K   18.1M   1.51M   1.51M
    64       19    304K     19K     19K    1.63K   26.1M   1.63M   1.63M
   128        7    112K      7K      7K    1.26K   20.1M   1.26M   1.26M
   256        3     48K      3K      3K     1012   15.8M   1012K   1012K
   512        3     48K      3K      3K    2.01K   32.1M   2.01M   2.01M
    1K        2     32K      2K      2K    2.61K   41.7M   2.61M   2.61M
    2K        1     16K      1K      1K    2.31K   36.9M   2.31M   2.31M
 Total    2.35M   37.5G   20.1G   20.1G    2.51M   40.2G   21.5G   21.5G

Ważne pola to Łącznie przydzielone bloki i Łączne bloki odniesienia. W powyższym przykładzie mam niski współczynnik deduplikacji. 40,2G jest przechowywane na dysku w 37,5G miejsca. Lub 2,51 miliona bloków w przestrzeni o powierzchni 2,35 miliona bloków.

Aby uzyskać rzeczywisty rozmiar stołu, zobacz:

Wpisy DDT 2459286, rozmiar 481 na dysku, 392 w rdzeniu

2459286 * 392 = 964040112 bajtów Podziel przez 1024 i 1024, aby uzyskać: 919,3 MB pamięci RAM .

ewwhite
źródło
1
przepraszam za bycie gęstym ... w podanym przez ciebie przykładzie, jak mogę określić, jak duża jest tabela dedpue , a konkretnie ile pamięci RAM / L2ARC zużywa?
Josh
1
Zobacz zaktualizowany post.
ewwhite
1
Szczególnie podoba mi się przykład DDT @ ewwhite, ponieważ stanowi on również gwiezdny przykład stosunku, który w ogóle wyklucza stosowanie deduplikacji. Zfs wysyłałbym / odzyskiwał zestawy danych w tej puli, od deduplikowanych zestawów danych do niez deduplikowanych zestawów danych, i uważam się za szczęściarza, że ​​wciąż były wystarczająco małe, aby to zarządzać. :) Zachowaj ostrożność, zakładając, że twoje wartości Zvols będą dedupe. Jako deduplikacja na poziomie bloku, jedna różnica przesunięcia może wypaczyć całość. Jeśli mam jakąś radę, przenoszę góry, aby przetestować zestaw danych produkcyjnych w laboratorium TEST / przed / umieszczeniem deduplikacji ZFS w dowolnym środowisku produkcyjnym.
Nex7
constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe ma kilka dobrych informacji na temat obliczania oczekiwanych wygranych z deduplikacji i oczekiwanych kosztów.
jlp
Ta odpowiedź wymagała aktualizacji, nie była jeszcze kompletna. Bardziej szczegółowa odpowiedź znajduje się poniżej
Stilez,
5

Po przeczytaniu oryginalnego wątku e-mail i odpowiedzi @ ewwhite, która go wyjaśniła, myślę, że to pytanie wymaga zaktualizowanej odpowiedzi, ponieważ powyższa odpowiedź obejmuje tylko połowę.

Jako przykład użyjmy danych wyjściowych z mojej puli. Użyłem polecenia zdb -U /data/zfs/zpool.cache -bDDD My_pool. W moim systemie potrzebowałem dodatkowego -Uargumentu, aby zlokalizować plik pamięci podręcznej ZFS dla puli, który FreeNAS przechowuje w innej lokalizacji niż normalna; być może będziesz musiał to zrobić lub nie. Z reguły spróbuj najpierw zdbbez -U, a jeśli wystąpi błąd pliku pamięci podręcznej, użyj find / -name "zpool.cache"lub podobnie, aby zlokalizować potrzebny plik.

To był mój faktyczny wynik i zinterpretowałem go poniżej:

DDT-sha256-zap-duplicate: 771295 entries, size 512 on disk, 165 in core

bucket              allocated                       referenced
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     2     648K   75.8G   68.6G   68.8G    1.39M    165G    149G    149G
     4    71.2K   8.07G   6.57G   6.62G     368K   41.7G   34.1G   34.3G
     8    28.1K   3.12G   2.34G   2.36G     281K   31.0G   23.1G   23.4G
    16    5.07K    424M    232M    241M     110K   9.10G   5.06G   5.24G
    32    1.09K   90.6M   51.8M   53.6M    45.8K   3.81G   2.21G   2.28G
    64      215   17.0M   8.51M   8.91M    17.6K   1.39G    705M    739M
   128       38   2.12M    776K    872K    6.02K    337M    118M    133M
   256       13    420K   21.5K     52K    4.63K    125M   7.98M   18.5M
   512        3      6K      3K     12K    1.79K   3.44M   1.74M   7.16M
    1K        1    128K      1K      4K    1.85K    237M   1.85M   7.42M
    2K        1     512     512      4K    3.38K   1.69M   1.69M   13.5M

DDT-sha256-zap-unique: 4637966 entries, size 478 on disk, 154 in core

bucket              allocated                       referenced
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    4.42M    550G    498G    500G    4.42M    550G    498G    500G


DDT histogram (aggregated over all DDTs):

bucket              allocated                       referenced
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    4.42M    550G    498G    500G    4.42M    550G    498G    500G
     2     648K   75.8G   68.6G   68.8G    1.39M    165G    149G    149G
     4    71.2K   8.07G   6.57G   6.62G     368K   41.7G   34.1G   34.3G
     8    28.1K   3.12G   2.34G   2.36G     281K   31.0G   23.1G   23.4G
    16    5.07K    424M    232M    241M     110K   9.10G   5.06G   5.24G
    32    1.09K   90.6M   51.8M   53.6M    45.8K   3.81G   2.21G   2.28G
    64      215   17.0M   8.51M   8.91M    17.6K   1.39G    705M    739M
   128       38   2.12M    776K    872K    6.02K    337M    118M    133M
   256       13    420K   21.5K     52K    4.63K    125M   7.98M   18.5M
   512        3      6K      3K     12K    1.79K   3.44M   1.74M   7.16M
    1K        1    128K      1K      4K    1.85K    237M   1.85M   7.42M
    2K        1     512     512      4K    3.38K   1.69M   1.69M   13.5M
 Total    5.16M    638G    576G    578G    6.64M    803G    712G    715G

dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39

Co to wszystko oznacza i ustalenie rzeczywistego rozmiaru tabeli deduplikacji:

Dane wyjściowe pokazują dwie podtabele , jedną dla bloków, w których istnieje duplikat ( DDT-sha256-zap-duplicate ), a drugą dla bloków, w których duplikat nie istnieje ( DDT-sha256-zap-unique ) /. Trzecia tabela poniżej zawiera ogólną sumę dla obu tych elementów, a poniżej znajduje się wiersz podsumowania. Patrząc tylko na „sumaryczne” wiersze i podsumowanie, daje nam to, czego potrzebujemy:

Rozmiar DDT dla wszystkich bloków, które pojawiają się więcej niż jeden raz („DDT-sha256-zap-duplicate”) :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")

Rozmiar DDT dla bloków, które są unikalne („DDT-sha256-zap-unique”) :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")

Łączne statystyki DDT dla wszystkich wpisów DDT, powielone + niepowtarzalne („Histogram DDT zagregowany dla wszystkich DDT”) :

                    allocated                       referenced
          (= disk space actually used)      (= amount of data deduped 
                                                 into that space)
______   ______________________________   ______________________________
         blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE

 Total    5.16M    638G    576G    578G    6.64M    803G    712G    715G

Podsumowanie :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39

Zróbmy trochę chrupania liczb.

  • Liczba bloków działa w następujący sposób: Liczba wpisów związanych z duplikatami bloków = 771295, liczba wpisów związanych z unikalnymi blokami = 4637966, całkowita liczba wpisów w tabeli DDT powinna wynosić 771295 + 4637966 = 5409261. Tak więc liczba bloków w milionach (milionach binarnych to znaczy!) wyniesie 5409261 / (1024 ^ 2) = 5,158 miliona. Podsumowując, stwierdzamy, że w sumie jest 5,16 mln bloków .

  • Potrzebna pamięć RAM działa w następujący sposób: każdy z 771295 wpisów dla duplikatów bloków zajmuje 165 bajtów w pamięci RAM, a każdy 4646966 wpisów dla unikalnych bloków zajmuje 154 bajty w pamięci RAM, więc całkowita pamięć RAM potrzebna teraz dla tabeli deduplikacji = 841510439 bajtów = 841510439 / (1024 ^ 2) MBytes = 803 MB = 0,78 GB pamięci RAM .

    (Użyty rozmiar dysku można obliczyć w ten sam sposób, używając liczb „rozmiar na dysku”. Najwyraźniej ZFS stara się efektywnie wykorzystywać dyskowe operacje we / wy i wykorzystując fakt, że miejsce na dysku zajmowane przez DDT nie jest to zwykle problem. Wygląda więc na to, że ZFS po prostu przydziela pełny 512-bajtowy sektor dla każdego wpisu lub coś w tym stylu, zamiast tylko 154 lub 165 bajtów, aby utrzymać jego wydajność. Może to nie obejmować żadnego limitu dla wielu kopie przechowywane na dysku, co zwykle robi ZFS.)

  • Całkowita ilość przechowywanych danych i korzyści z ich dedukcji: Ze statystyk DDT ogółem 715 GB („715 G”) danych jest przechowywanych przy użyciu zaledwie 578 GB („578 G”) przydzielonego miejsca na dyskach. Tak więc nasz współczynnik oszczędności miejsca deduplikacji wynosi (715 GB danych) / (578 GB miejsca wykorzystanego po deduplikacji) = 1,237 x, co mówi nam podsumowanie („dedup = 1,24”).

Stilez
źródło