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

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

Mantenha o espaço do pool com uma utilização de 80% para manter o desempenho do pool. Atualmente, o desempenho do pool pode diminuir quando um pool está muito cheio e os sistemas de arquivos são atualizados com freqüência, como em um servidor de correio ocupado. Pools completos podem causar uma penalidade no desempenho, mas nenhum outro problema. [...] Lembre-se de que mesmo com conteúdo principalmente estático na faixa de 95 a 96%, o desempenho de gravação, leitura e resilversão pode sofrer. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)

Agora, suponha que eu tenha um pool de 10T raidz2 hospedando um sistema de arquivos ZFS volume. Agora, crio um sistema de arquivos filho volume/teste faço uma reserva de 5T.

Em seguida, montei os dois sistemas de arquivos por NFS em algum host e realizo algum trabalho. Entendo que não posso gravar em volumemais de 5T, porque os 5T restantes estão reservados volume/test.

Minha primeira pergunta é: como o desempenho diminuirá se eu preencher meu volumeponto de montagem com ~ 5T? Vai cair, porque não há espaço livre nesse sistema de arquivos para a cópia na gravação do ZFS e outras meta-coisas? Ou permanecerá 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 alguma diferença se eu alterar a configuração da seguinte maneira? volumeagora possui dois sistemas de arquivos volume/test1e 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? Vai cair, ou permanecerá o mesmo?

Obrigado!

Sim. Você precisa manter 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 para um zvol, mas não NFS.

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

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 bloco livre empregado com o ZFS. Ao contrário de outros sistemas de arquivos como NTFS ou ext3, não há bitmap de bloco mostrando quais blocos estão ocupados e quais são livres. Em vez disso, o ZFS divide seu zvol em (geralmente 200) áreas maiores chamadas "metaslabs" e armazena as árvores AVL ¹ de informações de bloco gratuitas (mapa de espaço) em cada metasslab. A árvore AVL balanceada permite uma busca eficiente de um bloco adequado ao tamanho da solicitação.

Embora esse 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 de espaço. Assim que todos os metasslabs transportam 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 o pool está vazio. Se o ZFS precisar alocar 2 MB de espaço, ele começará a ler e avaliar os mapas espaciais de todos os metaslabs para encontrar um bloco adequado ou uma maneira de dividir os 2 MB em blocos menores. Isso, claro, leva algum tempo. O pior é o fato de que custará muitas operações de E / S, pois o ZFS de fato leria todos os mapas de espaço dos discos físicos . Para qualquer uma de suas gravações.

A queda no desempenho pode ser significativa. Se você gosta de imagens bonitas, dê uma olhada na publicação no Delphix, que tem alguns números retirados de um pool zfs (simplificado, mas ainda válido). Estou roubando descaradamente um dos gráficos - observe as linhas azul, vermelha, amarela e verde neste gráfico, que representam (respectivamente) os conjuntos com 10%, 50%, 75% e 93% de capacidade desenhada contra a taxa de transferência de gravação em KB / s enquanto se fragmenta com o tempo:

Uma solução rápida e suja para isso tem sido tradicionalmente o modo de depuração do metaslab (apenas echo metaslab_debug/W1 | mdb -kwem tempo de execução para alterar instantaneamente a configuração). Nesse caso, todos os mapas de espaço seriam mantidos na RAM do SO, removendo o requisito de E / S excessiva e cara em cada operação de gravação. Por fim, isso também significa que você precisa de mais memória, especialmente para grandes pools, por isso é uma espécie de RAM para o comércio de cavalos. Seu pool de 10 TB provavelmente custará de 2 a 4 GB de memória ² , mas você poderá direcioná-lo para 95% de utilização sem muito aborrecimento.

¹ é um pouco mais complicado, se você estiver interessado, veja o post de Bonwick nos mapas espaciais para obter detalhes

² Se você precisar calcular um limite superior para a memória, use zdb -mm <pool>para recuperar o número segmentsatualmente em uso em cada metasslab, divida-o por dois para modelar o pior cenário (cada segmento ocupado seria seguido por um livre) ), multiplique pelo tamanho do registro para 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, somariam 32 bytes, embora as pessoas pareçam geralmente assumir 64 bytes para alguns razão).

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

Referência: o esboço básico está contido nesta postagem por Markus Kovero na lista de discussão do zfs-discuss , embora eu acredite que ele tenha cometido alguns erros no cálculo, que espero ter corrigido no meu.