☰

Desvantagens de usar o tamanho de registro ZFS 16k em vez de 128k

tag-icon • tag-icon zfs qemu performance-tuning
Desvantagens de usar o tamanho de registro ZFS 16k em vez de 128k

Estou usando o Proxmox em um servidor dedicado. Para produção ainda uso o ext4, mas resolvi começar a brincar com o ZFS.

Portanto, criei dois pools de armazenamento ZFS separados com tamanhos de registros diferentes:

  • 128k para tudo, exceto MySQL/InnoDB
  • 16k para MySQL/InnoDB (porque 16k é o tamanho de página padrão do InnoDB que estou usando)

Eu adicionei aquele pool de 16k para verificar se isso realmente faz diferença no desempenho do banco de dados MySQL/InnoDB. Então realmente acontece. Tenho cerca de 40% mais transações por segundo e latência 25% menor (testei isso exaustivamente combanco de dadosetpcc).

Por razões práticas, neste momento eu preferiria usar um grande pool com tamanho de registro de 16k em vez de duas partes separadas (16k e 128k).Eu sei que posso criar subvolumes em um único pool ZFS e fornecer tamanhos de registros diferentes, mas isso também é algo que quero evitar. Prefiro manter isso gerenciável na GUI do Proxmox.

Minhas perguntas:

  1. Que desvantagens posso encontrar se começar a usar um tamanho de registro pequeno (16k) para tudo em vez de 128k (era o padrão no Proxmox)?

  2. A imagem de disco QEMU tem equivalente a innodb_page_size? Se isso acontecer - qual é o tamanho?

    Eu tentei verificar isso com qemu-img info:

     $ qemu-img info vm-100-disk-0.raw
 image: vm-100-disk-0.raw
 file format: raw
 virtual size: 4 GiB (4294967296 bytes)
 disk size: 672 MiB

O uso do servidor é:

  • contêineres para www/php (toneladas de arquivos pequenos, mas dentro de um arquivo de disco contêiner)
  • contêineres para aplicativos java/spring (eles produzem muitos logs)
  • contêineres para bancos de dados mysql/innodb (nenhuma explicação necessária)
  • operações locais de backup/restauração, incluindo compactação de backups
  • mexer com arquivos gzip grandes (não todos os dias, baixa prioridade)

Responder1

Resposta curta:Realmente depende do seu caso de uso esperado. Como regra geral, o tamanho de registro padrão de 128K é uma boa escolha em discos mecânicos (onde a latência de acesso é dominada pelo tempo de busca + atraso rotacional). Para um pool totalmente SSD, eu provavelmente usaria 16K ou no máximo 32K (somente se este último fornecer um aumento significativo na eficiência de compactação para seus dados).

Resposta longa:Com um pool de HDD, recomendo manter o tamanho de registro padrão de 128K para conjuntos de dados e usar volblocksize de 128K para zvol também. A justificativa é que a latência de acesso para um HDD de 7,2K RPM é dominada pelo tempo de busca, o que nãonãoescala com recordize/volblocksize. Vamos fazer algumas contas: um HDD de 7,2K tem um tempo médio de busca de 8,3ms, enquanto a leitura de um bloco de 128K leva apenas cerca de 1ms. Portanto, comandar uma busca de cabeça (com atraso de 8 ms +) para ler pequenos blocos de 16K parece um desperdício, especialmente considerando que para leituras/gravações menores você ainda é prejudicado pela latência r/m/w. Além disso, um tamanho de registro pequeno significa uma maior sobrecarga de metadados e pior compactação. Portanto, embora o InnoDB emita IOs de 16K, e para um conjunto de dados dedicado, pode-se usar tamanho de registro de 16K para evitar r/m/w e amplificação de gravação, para conjuntos de dados de uso misto (ou seja: aqueles que você usa não apenas para o banco de dados em si, mas para conjuntos de dados mais gerais cargas de trabalho também) eu sugeriria ficar em 128K, especialmente considerando o impacto da compactação de registros pequenos.

No entanto, para um pool SSD, eu usaria um volblocksize/recordsize muito menor, possivelmente na faixa de 16-32K. A justificativa é que o SSD tem um tempo de acesso muito menor, mas resistência limitada, portanto, escrever um bloco completo de 128K para gravações menores parece excessivo. Além disso, a amplificação da largura de banda IO comandada por registros grandes é muito mais preocupante em um dispositivo com IOPs altos do que em SSDs modernos (ou seja: você corre o risco de saturar sua largura de bandaantesatingindo o limite de PIO).

Responder2

Eu recomendo afinarse e quandovocê encontra um problema.

O padrão do ZFS é tamanho de registro de 128K, e isso é aceitável e válido para a maioria das configurações e aplicativos.

Exceções a isso incluem:

  • certos aplicativos de banco de dados; um valor menor pode ser apropriado.
    A desvantagem é que a compactação será muito menos eficaz, o que pode ter um impacto maior no desempenho do que a contagem mais alta de transações!!
  • grandes cargas de trabalho de mídia (por exemplo, edição de vídeo); um valor maior é útil
  • cargas de trabalho específicas que estão fora dos casos de uso normais do ZFS

Se você acha que o desempenho do benchmark do banco de dados é melhor com um determinado tamanho de registro, use-o!
Mas você testou com um realistasem benchmarkingcarga de trabalho para ter certeza de que você está se ajustando para a coisa certa?

Responder3

Pelo que vale, é uma recomendação definir "recordsize=16K" de acordo com a própria documentação do zfs.

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodb

EDIT: Acabei de reverter essa configuração depois de alterá-la por menos de 12 horas em um servidor proxmox para um servidor virtual com um banco de dados bastante grande (> 60 GB de dados). O servidor ficou seriamente para trás na análise de dados. Na verdade, o 'z_rd_int_'os processos saltaram de um baixo uso de CPU para cerca de 5% cada, enquanto o 'z_wr_int_'processado caiu no uso da CPU - provavelmente porque menos dados foram tratados.

No entanto, alterar o algoritmo hash para edonr( zfs set checksum=edonr vmpool) teve um impacto positivo: perf topnão aparece mais SHA256TransformBlockscomo a função do kernel superior.

Portanto, a recomendação não parece ser boa em todos os casos – ela pode ser revertida para o conjunto original.

informação relacionada