Otimizar o desempenho do hiperdisco

Depois de provisionar os volumes do Google Cloud Hyperdisk, o aplicativo e o sistema operacional podem exigir ajuste de desempenho para atender às necessidades de desempenho.

Nas seções a seguir, descrevemos alguns elementos principais que podem ser ajustados para melhor desempenho e como aplicar alguns deles a tipos específicos de cargas de trabalho.

Para uma visão geral de como funciona o desempenho do Google Cloud Hyperdisk, consulte Sobre o desempenho do Hyperdisk.

Use uma profundidade de fila de E/S alta

Os volumes de hiperdisco têm latência maior do que os discos conectados localmente, como SSDs locais, porque são dispositivos conectados à rede. Eles podem fornecer IOPS e capacidade muito altas, mas você precisa garantir que solicitações de E/S suficientes sejam realizadas em paralelo. O número de solicitações de E/S feitas em paralelo é chamado de profundidade da fila de E/S.

As tabelas a seguir mostram a profundidade de fila de E/S recomendada para garantir que você atinja um determinado nível de desempenho. As tabelas usam uma pequena superestimação da latência típica para mostrar recomendações conservadoras. O exemplo pressupõe que você esteja usando um tamanho de E/S de 16 KB.

IOPS desejadas Profundidade da fila
500 1
1.000 2
2.000 4
4.000 8
8.000 16
16.000 32
32.000 64
64.000 128
100.000 200
200.000 400
320.000 640
Capacidade desejada (MB/s) Profundidade da fila
8 1
16 2
32 4
64 8
128 16
256 32
512 64
1.000 128
1.200 153

Verifique se você tem CPUs livres

A leitura e a gravação de volumes em hiperdiscos exigem ciclos de CPU da VM. Se a instância de VM tiver pouca CPU, o aplicativo não conseguirá gerenciar as IOPS descritas acima. Para atingir níveis de IOPS muito altos e consistentes, as CPUs precisam estar livres para processar E/S.

Desativar a proteção contra gravação incompleta no nível do banco de dados para otimizar as gravações

Como o Hyperdisk do Google Cloud oferece proteção integrada contra gravações corrompidas, é possível desativar os recursos de proteção no nível do banco de dados para reduzir a sobrecarga de E/S e aumentar a capacidade de gravação do banco de dados em até 25%. Para saber mais sobre esse recurso, consulte Proteção contra gravação incompleta na página de visão geral do Hyperdisk.

Requisitos de configuração do ambiente

Para que a proteção contra gravação incompleta do Hyperdisk seja eficaz, as gravações do banco de dados não podem ser fragmentadas antes de chegar à camada de armazenamento. Dependendo do seu banco de dados, é possível fazer isso usando uma das seguintes opções de configuração:

Opção 1: alinhar camadas a limites de blocos de 16 KiB (recomendado para MySQL e PostgreSQL)

Configure o sistema operacional, o sistema de arquivos e as camadas intermediárias de software para preservar o limite de 16 KiB. Ao usar essa opção, você precisa manter esta configuração específica:

  • Sistema de arquivos: use um sistema de arquivos ext4. Crie o sistema de arquivos com a opção bigalloc e configure o tamanho do cluster do sistema de arquivos como 16 KiB (16.384 bytes) ou um múltiplo maior de potência de dois de 16 KiB:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<var>DEVICE_NAME</var>

    Substitua DEVICE_NAME pelo nome do dispositivo de armazenamento.

  • Configurações incompatíveis: evite configurações que possam introduzir gravações incompletas acima da camada de armazenamento em blocos, como as seguintes:

    • Executar bancos de dados conteinerizados no Google Kubernetes Engine ou no Kubernetes autohospedado.
    • Armazenar arquivos de banco de dados em um sistema de arquivos xfs, que normalmente não oferece suporte a tamanhos de bloco suficientes na maioria das distribuições do Linux.
    • Usar configurações de matrizes redundantes de discos independentes (RAID) ou gerenciadores de volumes lógicos (LVM) que eliminam a E/S.
    • Usar o Hyperdisk com caches de SSD local, incluindo lvmcache, dm-cache ou bcache.
    • Usando a virtualização aninhada para a VM do banco de dados.

Opção 2: usar E/S atômica de bloco do Linux (recomendado para MariaDB)

Se seu banco de dados ou aplicativo oferecer suporte a E/S atômica de bloco do Linux e acessar arquivos usando E/S direta (O_DIRECT), você poderá ignorar as regras de configuração listadas na opção 1, desde que atenda às seguintes condições:

  • Flag RWF_ATOMIC: o aplicativo precisa usar a chamada de sistema pwritev2() com a flag RWF_ATOMIC. Ao usar essa flag, o kernel do Linux garante que uma operação de gravação seja processada como um único bloco contíguo pelo dispositivo Hyperdisk subjacente. Se o kernel não puder garantir a atomicidade, a chamada de gravação vai falhar imediatamente para evitar a corrupção de dados.
  • Sistema operacional: precisa ser a versão 6.11 ou mais recente do kernel do Linux.
  • Sistema de arquivos: precisa ser ext4 ou xfs na versão 6.13 ou mais recente do kernel do Linux.
  • Acesso a arquivos: o aplicativo precisa abrir arquivos de banco de dados usando E/S direta (O_DIRECT).
  • Bancos de dados compatíveis: recomendamos essa opção apenas para o MariaDB versão 11.x ou mais recente (para compatibilidade genérica com RWF_ATOMIC do Linux). O MySQL e o PostgreSQL não oferecem suporte a esse recurso.

Para instruções detalhadas de otimização específicas do banco de dados, consulte Configurar o MySQL no Compute Engine.

Analisar as métricas de desempenho do hiperdisco

Faça isso no Cloud Monitoring, a solução de monitoramento integrada doCloud de Confiance. É possível usar essas métricas para observar o desempenho dos discos e de outros recursos de VM em diferentes cargas de trabalho de aplicativos.

Para saber mais, consulte Como analisar métricas de desempenho de disco.

Também é possível usar a página Observabilidade no console para ver as métricas de desempenho do disco.

A seguir