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, Google Clouda 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