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

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

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

Selecione uma versão da documentação:

Nesta página, descrevemos 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 Grand Unified Configuration (GUC) 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 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 do O_DIRECT é um pré-requisito para gravações atômicas. O_DIRECT se aplica ao diretório de dados do PostgreSQL e ao cache em disco do AlloyDB Omni. Para mais informações, consulte Acelerar o desempenho do banco de dados usando o cache em 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 o overhead de CPU e memória do sistema operacional necessários 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 em disco do AlloyDB Omni usando AIO para aumentar o desempenho de leitura. Essa abordagem facilita a leitura antecipada eficaz de buffers do armazenamento para o pool de memória compartilhada 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 do kernel. 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 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 a verificação de compatibilidade de inicialização. Não é possível iniciar 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

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 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 depois 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 em disco do AlloyDB Omni. Para mais informações, consulte Acelerar o desempenho do banco de dados usando o cache em disco.

Observação: o cache em 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.
Baixe 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: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 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 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 limpeza e pré-aquecimento do cache em 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 arquitetônicas.
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.