Desempenho do ZFS: preciso manter espaço livre em um pool ou em um sistema de arquivos?

Question

Eu sei que o desempenho do ZFS depende muito da quantidade de espaço livre:

Keep pool space under 80% utilization to maintain pool performance. Currently, pool performance can degrade when a pool is very full and file systems are updated frequently, such as on a busy mail server. Full pools might cause a performance penalty, but no other issues. [...] Keep in mind that even with mostly static content in the 95-96% range, write, read, and resilvering performance might suffer. ZFS_Best_Practices_Guide, solarisinternals.com

Agora, suponha que eu tenha um pool raidz2 de 10T hospedando um sistema de arquivos do ZFS volume . Agora eu crio um sistema de arquivos filho volume/test e dou uma reserva de 5T.

Depois, montei os dois sistemas de arquivos por NFS em algum host e executei algum trabalho. Entendo que não posso escrever para volume mais que 5T, porque os 5T restantes estão reservados para volume/test .

Minha primeira pergunta é como o desempenho cai, se eu preencher meu ponto de montagem volume com ~ 5T? Será que vai cair, porque não há espaço livre no sistema de arquivos para o copy-on-write do ZFS e outros meta-stuff? Ou será o mesmo, já que o ZFS pode usar o espaço livre dentro do espaço reservado para volume/test ?

Agora, a segunda pergunta . Faz diferença se eu alterar a configuração da seguinte maneira? volume agora tem dois sistemas de arquivos, volume/test1 e volume/test2 . Ambos recebem uma reserva de 3T cada (mas sem cotas). Suponha agora, eu escrevo 7T para test1 . O desempenho dos dois sistemas de arquivos será o mesmo ou será diferente para cada sistema de arquivos? Será que vai cair ou permanecer o mesmo?

Obrigado!

    

Answer 1

Sim. Você precisa manter o espaço livre em sua piscina. É principalmente para ações de cópia na gravação e instantâneos. O desempenho diminui em cerca de 85% de utilização. Você pode ir mais alto, mas há um impacto definitivo.

Não mexa com reservas. Especialmente com o NFS. Não é necessário. Talvez por um zvol, mas não pelo NFS.

Eu não vejo a confusão, no entanto. Se você tem 10T, não use mais de 85% dele. Dimensione seus compartilhamentos adequadamente, usando quotas para limitar seu uso. Ou não use cotas e monitore seu uso geral do pool .

    

Answer 2

A degradação do desempenho ocorre quando o zpool está muito cheio ou muito fragmentado. A razão para isso é o mecanismo de descoberta de blocos livres empregado com o ZFS. Oposto a outros sistemas de arquivos como NTFS ou ext3, não há nenhum bitmap de bloco mostrando quais blocos estão ocupados e quais estão livres. Em vez disso, o ZFS divide seu zvol em (geralmente 200) áreas maiores chamadas "metaslabs" e armazena AVL-trees ¹ de informações de blocos livres (mapa de espaço) em cada metaslab. A árvore AVL balanceada permite uma busca eficiente por um bloco adequado ao tamanho da solicitação.

Embora este mecanismo tenha sido escolhido por razões de escala, infelizmente também se tornou uma grande dor quando ocorre um alto nível de fragmentação e / ou utilização do espaço. Assim que todos os metaslabs carregam uma quantidade significativa de dados, você obtém um grande número de pequenas áreas de blocos livres, em oposição a um pequeno número de grandes áreas quando a piscina está vazia. Se o ZFS precisar alocar 2 MB de espaço, ele começará a ler e avaliar todos os mapas de espaço do metaslabs para encontrar um bloco adequado ou uma maneira de dividir os 2 MB em blocos menores. Isso, claro, leva algum tempo. O que é pior é o fato de que custará um monte de operações de E / S, já que o ZFS realmente leu todos os mapas de espaço fora dos discos físicos . Para qualquer das suas gravações.

A queda no desempenho pode ser significativa. Se você gosta de fotos bonitas, dê uma olhada na postagem do no Delphix , que tem algumas números retirados de um pool zfs (supersimplificado mas ainda válido). Estou descarnando furiosamente um dos gráficos - observe as linhas azul, vermelha, amarela e verde neste gráfico que representam (respectivamente) conjuntos a 10%, 50%, 75% e 93% da capacidade obtida em relação à taxa de transferência em KB / s ao se tornar fragmentado ao longo do tempo:

Umrápido&Umconsertosujoparaissotemsidotradicionalmenteomododedepuraçãometaslab(apenasemitaechometaslab_debug/W1|mdb-kwemtempodeexecuçãoparaalterarinstantaneamenteaconfiguração).Nessecaso,todososmapasdeespaçoseriammantidosnoOSRAM,removendoorequisitodeE/Sexcessivaedispendiosaemcadaoperaçãodegravação.Emúltimaanálise,issotambémsignificaquevocêprecisademaismemória,especialmenteparagrandespools,porissoéumaespéciedeRAMparaocomérciodecavalosdearmazenamento.Seupoolde10TBprovavelmentecustará2-4GBdememória²,masvocêpoderádirecionarpara95%deutilizaçãosemmuitacomplicação.

¹éumpoucomaiscomplicado,sevocêestiverinteressado,veja post de Bonwick em mapas espaciais para detalhes

² se você precisar calcular um limite superior para a memória, use zdb -mm <pool> para recuperar o número de segments atualmente em uso em cada metaslab, divida-o por dois para modelar na pior das hipóteses (cada segmento ocupado seria seguido por um livre), multiplique-o pelo tamanho do registro de um nó AVL (dois ponteiros de memória e um valor, dada a natureza de 128 bits do zfs e o endereçamento de 64 bits soma até 32 bytes, embora as pessoas pareçam geralmente assumir 64 bytes por algum motivo).

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

Referência: o esquema básico está contido em esta postagem de Markus Kovero no zfs- discutir lista de discussão , embora eu acredite que ele cometeu alguns erros em seu cálculo, que espero ter corrigido no meu.