Wie groß ist meine ZFS-Deduplizierungstabelle derzeit?

21

Ich habe viele Informationen zur Planung der RAM-Anforderungen für die ZFS-Deduplizierung gelesen. Ich habe gerade das RAM meines Dateiservers aktualisiert, um einige sehr eingeschränkte Deduplizierungsfunktionen für ZFS-ZVOLs zu unterstützen, auf denen ich keine Snapshots und Klone verwenden kann (da ZVOLs als anderes Dateisystem formatiert sind), die jedoch viele duplizierte Daten enthalten.

Ich möchte sicherstellen, dass der neu hinzugefügte RAM die begrenzte Deduplizierung unterstützt, die ich beabsichtige. In der Planung sehen meine Zahlen gut aus, aber ich möchte sicher sein .

Wie kann ich die aktuelle Größe der ZFS-Dedupe-Tabellen (DDTs) auf meinem Live-System ermitteln? Ich habe diesen Mailinglisten-Thread gelesen, aber mir ist nicht klar, wie sie zu diesen Zahlen kommen. (Ich kann zdb tankbei Bedarf die Ausgabe von posten, suche aber nach einer generischen Antwort, die anderen helfen kann.)

Josh
quelle

Antworten:

17

Sie können den zpool status -D poolnameBefehl verwenden.

Die Ausgabe würde ungefähr so ​​aussehen:

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

Die wichtigen Felder sind die Summe der zugewiesenen Blöcke und die Summe der referenzierten Blöcke. Im obigen Beispiel habe ich eine niedrige Deduplizierungsrate. 40,2 g werden auf der Festplatte in 37,5 g Speicherplatz gespeichert. Oder 2,51 Millionen Blöcke auf 2,35 Millionen Blöcken.

Informationen zur tatsächlichen Größe der Tabelle finden Sie unter:

DDT-Einträge 2459286, Größe 481 auf Platte, 392 im Kern

2459286 * 392 = 964040112 Bytes Teilen Sie durch 1024 und 1024, um 919,3 MB RAM zu erhalten .

ewwhite
quelle
1
Ich entschuldige mich für die hohe Dichte. Wie kann ich in dem von Ihnen angegebenen Beispiel feststellen, wie groß die dedpue- Tabelle ist, insbesondere wie viel RAM / L2ARC sie verbraucht?
Josh
1
Siehe aktualisierten Beitrag.
Ewwhite
1
Ich mag @ ewwhite's Beispiel DDT besonders, weil es auch ein hervorragendes Beispiel für ein Verhältnis ist, das die Verwendung von Deduplizierung überhaupt ausschließt. Ich würde zfs die Datensätze in diesem Pool senden / zurückerhalten, von dedupierten Datensätzen zu nicht dedupierten Datensätzen, und ich würde mich glücklich schätzen, dass sie noch klein genug waren, um dies handhabbar zu machen. :) Sei vorsichtig, vorausgesetzt, deine Zvols werden enttäuscht. Als Deduplizierung auf Blockebene kann eine einzelne Offsetdifferenz das Ganze verzerren. Wenn ich einen Rat habe, ist es ratsam, Berge zu versetzen, um den Produktionsdatensatz in einem TEST-Labor zu testen, bevor ZFS-Deduplizierung in eine Produktionsumgebung eingefügt wird.
Nex7,
constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe hat einige gute Informationen zur Berechnung Ihrer erwarteten Gewinne aus Dedup und Ihrer erwarteten Kosten.
jlp
Diese Antwort brauchte ein Update, es war nicht ganz vollständig.
Weiter
5

Nachdem ich den Original-E-Mail-Thread und die Antwort von @ ewwhite gelesen habe , die ihn geklärt hat, denke ich, dass diese Frage eine aktualisierte Antwort benötigt, da die Antwort oben nur die Hälfte davon abdeckt.

Verwenden wir als Beispiel die Ausgabe in meinem Pool. Ich habe den Befehl verwendet zdb -U /data/zfs/zpool.cache -bDDD My_pool. Auf meinem System benötigte ich das zusätzliche -UArgument, um die ZFS-Cache-Datei für den Pool zu finden, die FreeNAS an einem anderen Ort als normal speichert. Möglicherweise müssen Sie das tun oder nicht. Versuchen Sie es im Allgemeinen zuerst zdbohne. -UWenn ein Cache-Dateifehler auftritt, suchen Sie die benötigte Datei mit find / -name "zpool.cache"o.ä.

Dies war meine eigentliche Ausgabe und ich habe es unten interpretiert:

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

Was das alles bedeutet und wie hoch die tatsächliche Größe der Dedup-Tabelle ist:

Die Ausgabe zeigt zwei Untertabellen, eine für Blöcke, in denen ein Duplikat vorhanden ist ( DDT-sha256-zap-duplicate ) und eine für Blöcke, in denen kein Duplikat vorhanden ist ( DDT-sha256-zap-unique ). Die dritte Tabelle darunter gibt eine Gesamtsumme für beide an, und darunter befindet sich eine zusammenfassende Zeile. Wenn wir uns nur die "Gesamt" -Zeilen und die Zusammenfassung ansehen, erhalten wir, was wir brauchen:

DDT-Größe für alle Blöcke, die mehrmals vorkommen ("DDT-sha256-zap-duplicate") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")

DDT-Größe für Blöcke, die eindeutig sind ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")

DDT-Gesamtstatistik für alle DDT-Einträge, doppelt + eindeutig ("DDT-Histogramm über alle DDTs aggregiert") :

                    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

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

Lass uns ein bisschen Zahlen knacken.

  • Die Blockanzahl funktioniert wie folgt : Anzahl der Einträge in Bezug auf doppelte Blöcke = 771295, Anzahl der Einträge in Bezug auf eindeutige Blöcke = 4637966, Gesamteinträge in der DDT-Tabelle sollten 771295 + 4637966 = 5409261 sein. Die Anzahl der Blöcke in Millionen (binäre Millionen) das heißt!) wäre 5409261 / (1024 ^ 2) = 5,158 Millionen. In der Zusammenfassung finden wir insgesamt 5,16 Millionen Blöcke .

  • Der benötigte RAM funktioniert folgendermaßen: Die 771295-Einträge für doppelte Blöcke belegen jeweils 165 Bytes im RAM und die 4637966-Einträge für eindeutige Blöcke belegen jeweils 154 Bytes im RAM, sodass der gesamte für die Dedup-Tabelle derzeit benötigte RAM = 841510439 Bytes = 841510439 / (1024 ^ 2) MB = 803 MB = 0,78 GB RAM .

    (Die auf der Festplatte verwendete Größe kann auf die gleiche Weise unter Verwendung der "Größe auf der Festplatte" berechnet werden. ZFS versucht offensichtlich, die Festplatten-E / A effizient zu nutzen und nutzt die Tatsache, dass der vom DDT belegte Festplattenspeicher nicht ausreicht Normalerweise ist das kein Problem. Daher sieht es so aus, als würde ZFS einfach einen kompletten 512-Byte-Sektor für jeden Eintrag zuweisen oder etwas in diese Richtung, anstatt nur 154 oder 165 Byte, um die Effizienz zu erhalten Kopien, die auf der Festplatte gespeichert sind (was ZFS normalerweise tut).

  • Die Gesamtmenge der gespeicherten Daten und der Vorteil der Deduktion: Aus der DDT-Gesamtstatistik ergeben sich 715 GB ("715 G") Daten, die nur 578 GB ("578 G") zugewiesenen Speicherplatz auf den Datenträgern belegen. Unser Verhältnis zur Einsparung von Dedup-Speicherplatz beträgt also (715 GB Daten) / (578 GB Speicherplatz, der nach dem Dedup-Vorgang verwendet wird) = 1,237 x. Dies wird in der Zusammenfassung angegeben ("Dedup = 1,24").

Stilez
quelle