Eu li muitas informações sobre o planejamento de requisitos de RAM para desduplicação do ZFS. Acabei de atualizar a RAM do meu servidor de arquivos para oferecer suporte a algumas desduplicações muito limitadas nos zvols do ZFS, nas quais não posso usar snapshots e clones (pois eles são zvols formatados como um sistema de arquivos diferente), mas ainda contêm muitos dados duplicados.
Quero ter certeza de que a nova RAM que adicionei oferecerá suporte à desduplicação limitada que pretendo fazer. No planejamento, meus números parecem bons, mas quero ter certeza .
Como posso saber o tamanho atual das DDTs do ZFS no meu sistema ativo? Eu li esse tópico da lista de discussão, mas não sei como eles estão chegando a esses números. (Posso postar a saída de, zdb tank
se necessário, mas estou procurando uma resposta genérica que possa ajudar outras pessoas)
Depois de ler o tópico do email original e a resposta da @ ewwhite que o esclareceu, acho que essa pergunta precisa de uma resposta atualizada, pois a resposta acima cobre apenas metade dela.
Como exemplo, vamos usar a saída no meu pool. Eu usei o comando
zdb -U /data/zfs/zpool.cache -bDDD My_pool
. No meu sistema, eu precisava do-U
argumento extra para localizar o arquivo de cache ZFS do pool, que o FreeNAS armazena em um local diferente do normal; você pode ou não precisar fazer isso. Geralmente tentezdb
sem-U
primeiro e, se você receber um erro no arquivo em cache, usefind / -name "zpool.cache"
ou similar para localizar o arquivo necessário.Esta foi a minha saída real e a interpretei abaixo:
O que tudo isso significa e calculando o tamanho real da tabela de deduplicação:
A saída mostra duas sub-tabelas, uma para blocos onde existe uma duplicata ( DDT-sha256-zap-duplicate ) e outra para blocos onde não existe duplicata ( DDT-sha256-zap-unique ) /. A terceira tabela abaixo deles fornece um total geral em ambos, e há uma linha de resumo abaixo disso. Examinar apenas as linhas "totais" e o resumo nos fornece o que precisamos:
Vamos fazer uma trituração de números.
A contagem de blocos funciona assim: Número de entradas relacionadas a blocos duplicados = 771295, número de entradas relacionadas a blocos exclusivos = 4637966, o total de entradas na tabela DDT deve ser 771295 + 4637966 = 5409261. Portanto, o número de blocos em milhões (milhões de binários isto é!) seria 5409261 / (1024 ^ 2) = 5,158 milhões. No resumo, descobrimos que existem 5,16 milhões de blocos no total .
A RAM necessária funciona da seguinte maneira: as entradas 771295 para blocos duplicados ocupam 165 bytes na RAM, e as entradas 4637966 para blocos únicos ocupam 154 bytes na RAM, portanto, o total de RAM necessário para a tabela de dedução agora = 841510439 bytes = 841510439 / (1024 ^ 2) MBytes = 803 MB = 0,78 GB de RAM .
(O tamanho em disco usado pode ser trabalhado da mesma maneira, usando as figuras "tamanho em disco". Claramente, o ZFS está tentando usar a E / S de disco com eficiência e aproveitando o espaço em disco ocupado pelo DDT. Portanto, parece que o ZFS está simplesmente alocando um setor completo de 512 bytes para cada entrada, ou algo nesse sentido, em vez de apenas 154 ou 165 bytes, para mantê-lo eficiente. Isso pode não incluir nenhuma permissão para vários cópias mantidas em disco, o que o ZFS geralmente faz.)
A quantidade total de dados armazenados e o benefício da desduplicação: Do total de estatísticas do DDT, 715 Gbytes ("715G") de dados são armazenados usando apenas 578 GBytes ("578G") de armazenamento alocado nos discos. Portanto, nossa taxa de economia de espaço de desduplicação é (715 GB de dados) / (578 GB de espaço usado após a desduplicação) = 1,237 x, que é o que o resumo está nos dizendo ("dedup = 1,24").
fonte