Quelle est la taille de ma table de déduplication ZFS en ce moment?


21

J'ai lu beaucoup d'informations sur la planification des exigences de RAM pour la déduplication ZFS. Je viens de mettre à niveau la RAM de mon serveur de fichiers pour prendre en charge une déduplication très limitée sur les zvols ZFS sur lesquels je ne peux pas utiliser d'instantanés et de clones (car ils sont formatés en zvols comme un système de fichiers différent) mais contiendra beaucoup de données dupliquées.

Je veux m'assurer que la nouvelle RAM que j'ai ajoutée prendra en charge la déduplication limitée que j'ai l'intention de faire. Lors de la planification, mes chiffres semblent bons, mais je veux en être sûr .

Comment savoir la taille actuelle des tables de déduplication ZFS (DDT) sur mon système en direct? J'ai lu ce fil de liste de diffusion, mais je ne sais pas comment ils parviennent à ces numéros. (Je peux poster la sortie de zdb tanksi nécessaire mais je cherche une réponse générique qui peut aider les autres)

Réponses:


17

Vous pouvez utiliser la zpool status -D poolnamecommande.

La sortie ressemblerait à:

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

Les champs importants sont le total des blocs alloués et le total des blocs référencés. Dans l'exemple ci-dessus, j'ai un faible taux de déduplication. 40.2G est stocké sur disque dans 37.5G d'espace. Ou 2,51 millions de blocs dans 2,35 millions de blocs d'espace.

Pour obtenir la taille réelle du tableau, voir:

Entrées DDT 2459286, taille 481 sur disque, 392 dans le cœur

2459286 * 392 = 964040112 octets Divisez par 1024 et 1024 pour obtenir: 919,3 Mo de RAM .


1
mes excuses pour être dense ... dans l'exemple que vous avez fourni, comment puis-je déterminer la taille de la table dedpue , en particulier, combien de RAM / L2ARC elle consomme?
Josh

1
Voir l'article mis à jour.
ewwhite

1
J'aime particulièrement l'exemple DDT de @ ewwhite, car il constitue également un exemple stellaire d'un rapport qui empêche l'utilisation de la déduplication. Je voudrais envoyer / recevoir les ensembles de données sur ce pool, des ensembles de données dédoublés aux ensembles de données non dédoublés, et je me considère chanceux, ils étaient encore assez petits pour que cela soit gérable. :) Soyez prudent en supposant que vos zvols seront dédupliqués. En tant que déduplication au niveau du bloc, une seule différence de décalage pourrait fausser le tout. Si j'ai un conseil, c'est déplacer des montagnes pour tester l'ensemble de données de production dans un laboratoire TEST / avant / mettre la déduplication ZFS dans n'importe quel environnement de production.
Nex7

constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe a de bonnes informations sur le calcul de vos gains attendus de la déduplication et de vos coûts attendus.
jlp

Cette réponse avait besoin d'une mise à jour, elle n'était pas tout à fait complète. Voir ci-dessous pour une réponse plus détaillée
Stilez

5

Après avoir lu le fil de discussion d'origine et la réponse de @ ewwhite qui l'a clarifié, je pense que cette question a besoin d'une réponse mise à jour, car la réponse ci-dessus n'en couvre que la moitié.

À titre d'exemple, utilisons la sortie sur mon pool. J'ai utilisé la commande zdb -U /data/zfs/zpool.cache -bDDD My_pool. Sur mon système, j'avais besoin de l' -Uargument supplémentaire pour localiser le fichier de cache ZFS pour le pool, que FreeNAS stocke dans un emplacement différent de la normale; vous pouvez ou non avoir besoin de le faire. Essayez généralement zdbsans d' -Uabord, et si vous obtenez une erreur de fichier cache, utilisez find / -name "zpool.cache"ou similaire pour localiser le fichier dont il a besoin.

C'était ma sortie réelle et je l'ai interprétée ci-dessous:

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

Ce que tout cela signifie et calcul de la taille réelle de la table de déduplication:

La sortie affiche deux sous-tables, une pour les blocs où il existe un doublon ( DDT-sha256-zap-duplicate ) et une pour les blocs où aucun doublon n'existe ( DDT-sha256-zap-unique ) /. Le troisième tableau ci-dessous donne un total global pour les deux, et il y a une ligne récapitulative en dessous. En regardant uniquement les lignes "totales" et le résumé nous donne ce dont nous avons besoin:

Taille DDT pour tous les blocs qui apparaissent plusieurs fois ("DDT-sha256-zap-duplicate") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")

Taille DDT pour les blocs uniques ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")

Statistiques DDT totales pour toutes les entrées DDT, duplicata + unique ("Histogramme DDT agrégé sur tous les 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

Résumé :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39

Faisons quelques calculs.

  • Le nombre de blocs fonctionne comme ceci: Nombre d'entrées liées aux blocs en double = 771295, nombre d'entrées liées aux blocs uniques = 4637966, le nombre total d'entrées dans la table DDT doit être 771295 + 4637966 = 5409261. Ainsi, le nombre de blocs en millions (millions binaires c'est-à-dire!) serait 5409261 / (1024 ^ 2) = 5,158 millions. Dans le résumé, nous constatons qu'il y a au total 5,16 millions de blocs .

  • La RAM nécessaire fonctionne comme ceci: les 771295 entrées pour les blocs en double occupent chacune 165 octets en RAM, et les 4637966 entrées pour les blocs uniques occupent chacune 154 octets en RAM, donc la RAM totale nécessaire pour la table dedup en ce moment = 841510439 octets = 841510439 / (1024 ^ 2) Mo = 803 Mo = 0,78 Go de RAM .

    (La taille sur disque utilisée peut être calculée de la même manière, en utilisant les chiffres de "taille sur disque". Clairement, ZFS essaie d'utiliser efficacement les E / S disque et profite du fait que l'espace disque occupé par le DDT n'est pas n'est normalement pas un problème. Il semble donc que ZFS alloue simplement un secteur complet de 512 octets pour chaque entrée, ou quelque chose dans ce sens, au lieu de seulement 154 ou 165 octets, pour le garder efficace. Cela pourrait ne pas inclure de tolérance pour plusieurs copies conservées sur le disque, ce que fait généralement ZFS.)

  • La quantité totale de données stockées et les avantages de la déduplication: à partir des statistiques DDT totales, 715 Go ("715G") de données sont stockées en utilisant seulement 578 Go ("578G") de stockage alloué sur les disques. Notre taux d'économie d'espace de déduplication est donc de (715 Go de données) / (578 Go d'espace utilisé après le dédoublonnage) = 1,237 x, ce que nous dit le résumé ("dedup = 1,24").

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.