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)
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éralementzdbsans d'-Uabord, et si vous obtenez une erreur de fichier cache, utilisezfind / -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:
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:
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").
la source