Esta página documenta a versão 17.5.0 do AlloyDB Omni usando a opção de implantação de contêineres. Escolha outra opção de implantação.

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 dos 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 danificada
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 permite.

Proteção contra gravação danificada

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 operação da CPU do sistema e a sobrecarga de memória necessárias 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, que oferecem melhorias em verificações sequenciais, desempenho de 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 fazer a pré-busca de 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 no 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

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

Para usar os recursos de aceleração de E/S do AlloyDB Omni e testar ganhos de desempenho 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 proteção 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 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 configurações de 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 configurações de 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

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
...
```
Opcional: configure o cache em disco do AlloyDB Omni.

Use o exemplo a seguir para criar um sistema de arquivos usando ext4, e, em seguida, monte 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.

Observação: o cache de disco não precisa ser compatível com gravações atômicas porque os dados no cache são temporários. No entanto, os recursos de aceleração de E/S do AlloyDB Omni ainda usam O_DIRECT para acessar o cache.
Faça o download e execute o AlloyDB Omni.
1. Baixe o 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 extra, --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:17
```
  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 do 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.
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 17 contém caminhos que executam E/S de bloco único, o que O_DIRECT deixa mais lento. 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 o pré-lançamento.
Em cargas de trabalho pesadas, os sistemas baseados em ARM podem apresentar desempenho menor 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.