Melhorar a performance do AlloyDB Omni usando a aceleração de E/S

Selecione uma versão da documentação:

Esta página descreve como ativar um conjunto de recursos de aceleração de E/S no AlloyDB Omni que podem ajudar a melhorar a utilização de recursos de computação e E/S para cargas de trabalho mais rápidas e desempenho de consultas.

Os seguintes recursos estão incluídos:

  • Proteção contra gravação rasgada
  • Suporte do O_DIRECT
  • E/S assíncrona (AIO)
  • Leituras de streaming

Para ativar esses recursos de aceleração de E/S, habilite a configuração unificada geral (GUC, na sigla em inglês) alloydb_omni_atomic e configure o AlloyDB Omni para usar a GUC.

Recursos de aceleração de E/S

As seções a seguir descrevem os recursos de aceleração de E/S que o alloydb_omni_atomic GUC ativa.

Proteção contra gravação rasgada

Ao ativar a configuração alloydb_omni_atomic, você desativa as gravações de página inteira para evitar o excesso de desempenho de ter que gerar imagens de página inteira para registro em log.

Compatibilidade com O_DIRECT

O suporte ao O_DIRECT é um pré-requisito para gravações atômicas. O_DIRECT se aplica ao diretório de dados do PostgreSQL e ao cache de disco do AlloyDB Omni. Para mais informações, consulte Acelerar o desempenho do banco de dados usando o cache de disco.

O O_DIRECT também oferece os seguintes benefícios:

  • Usar O_DIRECT evita o problema de buffer duplo no PostgreSQL. O PostgreSQL gerencia o próprio cache de buffer e pode ignorar o cache de buffer do kernel do sistema operacional.
  • O O_DIRECT reduz a sobrecarga de CPU e memória do sistema operacional necessária para manter o cache de buffer do kernel.

E/S assíncrona

A configuração alloydb_omni_atomic oferece recursos de E/S assíncrona (AIO) usando as bibliotecas io_uring e libaio. Recomendamos usar io_uring para evitar as limitações da biblioteca libaio mais antiga. O AlloyDB Omni volta para libaio quando o suporte a io_uring não é detectado. Essa abordagem supera a perda de vantagens de E/S em buffer, como leitura antecipada e combinação de gravação, e também garante que a largura de banda de E/S disponível do armazenamento oferecido seja maximizada.

Leituras de streaming

O AlloyDB Omni usa leituras de streaming, semelhantes ao recurso do PostgreSQL 17, que oferecem melhorias em verificações sequenciais, ANALYZE e pg_prewarm usando E/S vetorizada para ler vários blocos no cache de buffer. A E/S vetorizada é um método em que uma única chamada de procedimento pode pré-buscar dados de vários buffers, o que melhora a eficiência ao reduzir as trocas de contexto e as chamadas de sistema.

O AlloyDB Omni estende o suporte para usar leituras de streaming do cache de disco do AlloyDB Omni usando AIO para aumentar o desempenho de leitura. Essa abordagem facilita a leitura antecipada eficaz de buffers para o pool de memória compartilhada do armazenamento para uso em consultas, em vez de ter que ler esses blocos do armazenamento sempre que eles são necessários.

Antes de começar

  1. Verifique se o sistema operacional e o sistema de arquivos são compatíveis.

    1. Para garantir que o kernel seja compatível com RWF_ATOMIC, verifique a versão dele. No exemplo a seguir, você usa uma máquina Ubuntu 24.10 executando o kernel Linux 6.14 que oferece suporte a gravações atômicas.

      > sudo hostnamectl
       ...
       Operating System: Ubuntu 24.10
            Kernel: Linux 6.14.0-061400rc5-generic
      ...
      
    2. Se o kernel não tiver suporte para RWF_ATOMIC, recomendamos que você atualize para uma versão que tenha.RWF_ATOMIC

  2. Para usar os recursos de aceleração de E/S do AlloyDB Omni e testar os ganhos de performance com proteção contra gravação incompleta, ative a alloydb_omni_atomic Grand Unification Configuration (GUC). Para usar essa GUC, você precisa ter um kernel e um sistema de arquivos compatíveis que forneçam E/S atômica e protejam contra gravações incompletas.

    A flag RWF_ATOMIC é usada para oferecer suporte à gravação atômica. Por padrão, a compatibilidade com RWF_ATOMIC é verificada durante a inicialização. O PostgreSQL não inicia se não for possível confirmar gravações atômicas com a flag RWF_ATOMIC.

    É possível substituir esse comportamento padrão, mas recomendamos usar uma plataforma compatível e a opção force para evitar a substituição acidental das configurações de configuração ideais.

    É possível substituir a verificação de compatibilidade do RWF_ATOMIC usando a opção force_unsafe, mas a segurança dos dados não é garantida com essa substituição. Recomendamos que você não use essa opção, a menos que esteja avaliando o AlloyDB Omni em um ambiente que não pode ser atualizado para usar o kernel e o sistema de arquivos adequados.

    A tabela a seguir lista as configurações de configuração alloydb_omni_atomic e as verificações de compatibilidade correspondentes.

    Valor alloydb_omni_atomic Verificação de compatibilidade de inicialização Descrição
    off
    N/A Esse valor desativa o modo atômico. O recurso está inativo.
    force
    Realiza uma verificação de compatibilidade de inicialização. Não inicia se a gravação de RWF_ATOMIC falhar. Define as configurações do modo atômico.
    force_unsafe
    Não realiza uma verificação de compatibilidade de inicialização. Retorna um aviso, mas continua se a gravação de RWF_ATOMIC falhar. Define as configurações do modo atômico.

    Na configuração force/force_unsafe, as configurações full_page_writes, io_combine_limit e debug_io_direct são definidas automaticamente. É possível substituir essas configurações usando a configuração opcional on/on_unsafe.

Configurar recursos de aceleração de E/S do AlloyDB Omni

  1. Configure o sistema de arquivos XFS para o diretório de dados. O XFS é usado porque aceita um tamanho de bloco do sistema de arquivos maior que o tamanho da página. O AlloyDB Omni pode usar o XFS para gravar atomicamente blocos de 8 KiB com suporte completo a RWF_ATOMIC.

    1. Crie um sistema de arquivos XFS com um tamanho de bloco de 8 KiB e monte-o no local desejado do diretório de dados (DATA_DIR).

      sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
      sudo mount /dev/$DEVICE DATA_DIR
      

      Faça a seguinte substituição:

      • DATA_DIR: o local do diretório de dados.
    2. Verifique os registros do kernel para garantir que blocos de 8k sejam usados:

      > sudo journalctl -f
      ...
      kernel: XFS (sdc): EXPERIMENTAL large block size feature enabled.  Use at your own risk!
      kernel: XFS (sdc): Mounting V5 Filesystem 350aa26a-7555-4566-94c1-74e54ddc9250
      ...
      
  2. Opcional: configure o cache de disco do AlloyDB Omni.

    Use o exemplo a seguir para criar um sistema de arquivos usando ext4, e montar o sistema de arquivos.

    sudo /sbin/mkfs.ext4 -m 1 -F -E lazy_itable_init=0,lazy_journal_init=0 /dev/DEVICE
    sudo mount --make-shared -o noatime,discard,errors=panic /dev/DEVICE /OMNI_DISK_CACHE_DIRECTORY
    

    Faça a seguinte substituição:

    • DEVICE: a entidade com que o aplicativo interage para realizar operações de E/S (leitura ou gravação de dados).

    Para oferecer suporte ao desempenho ideal dos recursos de aceleração de E/S do AlloyDB Omni quando o armazenamento principal não oferece mais operações de entrada/saída por segundo (IOPS), recomendamos configurar o cache de disco do AlloyDB Omni. Para mais informações, consulte Acelerar o desempenho do banco de dados usando o cache de disco.

  3. Faça o download e execute o AlloyDB Omni.

    1. Faça o download do contêiner Docker mais recente do AlloyDB Omni. Para mais informações, consulte Instalar o AlloyDB Omni em uma VM.
    2. Para usar o cache em disco, siga as instruções em Acelerar o desempenho do banco de dados usando o cache em disco.
    3. Para permitir io_uring, adicione um argumento, --security-opts="seccomp:unconfined"

      docker run -d --name CONTAINER_NAME \
         -e POSTGRES_PASSWORD=NEW_PASSWORD \
         -v DATA_DIR:/var/lib/postgresql/data \
         -v /OMNI_DISK_CACHE_DIRECTORY:/CACHE_DIRECTORY_PATH_INSIDE_CONTAINER \  # Only if disk cache is enabled
         -p HOST_PORT:5432 \
         --security-opts="seccomp:unconfined" \
         --restart=always \
         google/alloydbomni:16
      

      Faça as seguintes substituições:

      • CONTAINER_NAME: o nome do contêiner do AlloyDB Omni no registro de contêineres da máquina host.
      • NEW_PASSWORD: a senha atribuída ao usuário do PostgreSQL do contêiner.
      • DATA_DIR: o local do diretório de dados.
      • CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: o caminho do diretório de cache de disco dentro do contêiner.
      • HOST_PORT: a porta TCP na máquina host em que o contêiner vai publicar a própria porta 5432.
  4. Configure o AlloyDB Omni para usar E/S atômica.

    Defina a GUC alloydb_omni_atomic com um valor adequado e reinicie o contêiner.

    alter system set alloydb_omni_atomic='force';
    sudo docker restart CONTAINER_NAME;
    

    Faça as seguintes substituições:

    • CONTAINER_NAME: o nome do contêiner do AlloyDB Omni no registro de contêineres da máquina host.

Limitações

  • O PostgreSQL 16 contém caminhos que executam E/S de bloco único, o que O_DIRECT diminui a velocidade. Pode haver leituras mais lentas durante a recuperação do banco de dados (caminho de refazer), verificações de vácuo e pré-aquecimento do cache de disco do Omni.
  • Os recursos de aceleração de E/S do AlloyDB Omni em réplicas de leitura não são compatíveis com a prévia.
  • Em cargas de trabalho pesadas, os sistemas baseados em ARM podem apresentar desempenho inferior devido a diferenças de arquitetura.
  • Devido às limitações com o aumento das cargas de trabalho, o libaio está sujeito à indisponibilidade de recursos. O io_uring pode ter problemas de alocação de memória quando a memória disponível do sistema está baixa.