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 o desempenho do Google Cloud Hyperdisk funciona, 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 sem custo financeiro

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 corrompida no nível do banco de dados para otimizar as gravações

Como o Google Cloud Hyperdisk oferece proteção integrada contra gravação corrompida, é 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 corrompida na página de visão geral do Hyperdisk.

Requisitos de configuração do ambiente

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

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

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

  • Sistema de arquivos: use um sistema de arquivos ext4. É necessário criar o sistema de arquivos com a opção bigalloc e configurar o tamanho do cluster do sistema de arquivos para 16 KiB (16.384 bytes) ou um múltiplo maior 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 não compatíveis: evite configurações que possam introduzir gravações corrompidas acima da camada de armazenamento em blocos, como as seguintes:

    • Executar bancos de dados em contêiner no Google Kubernetes Engine ou no Kubernetes auto-hospedado.
    • 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 matrizes redundantes de configurações de discos independentes (RAID) ou gerenciadores de volume lógico (LVM) que removem a E/S.
    • Usar o Hyperdisk com caches de SSD local, incluindo lvmcache, dm-cache ou bcache.
    • Usar a virtualização aninhada para a VM do banco de dados.

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

Se o banco de dados ou aplicativo oferece suporte a E/S atômica de blocos do Linux e acessa arquivos usando E/S direta (O_DIRECT), é possível ignorar as regras de configuração listadas na opção 1, desde que você atenda às seguintes condições:

  • Flag RWF_ATOMIC: o aplicativo precisa usar a chamada do 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 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 a versão 11.x ou mais recente do MariaDB (para suporte genérico ao 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

Você pode revisar as métricas de desempenho do disco no Cloud Monitoring, Cloud de Confiancea solução de monitoramento integrada do. É 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