Qual é o tamanho da minha tabela de desduplicação do ZFS no momento?

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 tankse necessário, mas estou procurando uma resposta genérica que possa ajudar outras pessoas)

— Josh
fonte

Respostas:

Você pode usar o zpool status -D poolnamecomando

A saída seria semelhante a:

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

Os campos importantes são o total de blocos alocados e o total de blocos referenciados. No exemplo acima, tenho uma baixa taxa de deduplicação. 40.2G é armazenado em disco em 37.5G de espaço. Ou 2,51 milhões de blocos no espaço de 2,35 milhões de blocos.

Para obter o tamanho real da tabela, consulte:

Entradas DDT 2459286, tamanho 481 no disco, 392 no núcleo

2459286 * 392 = 964040112 bytes Divida por 1024 e 1024 para obter: 919,3MB na RAM .

— ewwhite
fonte

minhas desculpas por ser densa ... no exemplo que você forneceu, como posso determinar o tamanho da tabela dedpue , especificamente, quanto RAM / L2ARC ela consome?

— 27413 Josh

Veja postagem atualizada.

— precisa saber é

Gosto especialmente do exemplo DDT do @ ewwhite, porque também cria um exemplo estelar de uma proporção que impede o uso de deduplicação. Eu zfs enviava / recv os conjuntos de dados neste pool, de conjuntos de dados deduplicados a conjuntos de dados não-deduplicados, e me considero sortudo por ainda serem pequenos o suficiente para torná-los gerenciáveis. :) Cuidado, supondo que seus zvols serão desduplicados. Como deduplicação em nível de bloco, uma única diferença de deslocamento pode distorcer a coisa toda. Se eu tiver algum conselho, é mover montanhas para testar o conjunto de dados de produção em um laboratório de TESTE / antes / colocar a desduplicação do ZFS em qualquer ambiente de produção.

— Nex7

constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe possui boas informações sobre como calcular suas vitórias esperadas com a deduplicação e seus custos esperados.

— jlp

Esta resposta precisava de uma atualização, não estava completamente completa. Veja abaixo a resposta mais detalhada

— Stilez

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 -Uargumento 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 tente zdbsem -Uprimeiro e, se você receber um erro no arquivo em cache, use find / -name "zpool.cache"ou similar para localizar o arquivo necessário.

Esta foi a minha saída real e a interpretei abaixo:

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

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:

Tamanho do DDT para todos os blocos que aparecem mais de uma vez ("DDT-sha256-zap-duplicate") :
771295 entries, size 512 bytes on disk, 165 bytes in RAM ("core")

Tamanho do DDT para blocos únicos ("DDT-sha256-zap-unique") :
4637966 entries, size 478 bytes on disk, 154 bytes in RAM ("core")

Estatísticas totais de DDT para todas as entradas de DDT, duplicadas + exclusivas ("histograma do DDT agregado em todos os DDTs") :
                    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
Resumo :
dedup = 1.24, compress = 1.13, copies = 1.00, dedup * compress / copies = 1.39

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").

— Stilez
fonte