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:

Pré-lançamento — AlloyDB Omni

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Você pode gerenciar dados pessoais para este recurso conforme descrito no Aditivo sobre Tratamento de Dados do Cloud, sujeito às obrigações e restrições descritas no contrato que rege seu acesso ao Google Cloud. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições das fases de lançamento.

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 corrompida
Suporte a O_DIRECT
E/S assíncrona (AIO)
Leituras de streaming

Para ativar esses recursos de aceleração de E/S, ative 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 a GUC alloydb_omni_atomic ativa.

Proteção contra gravação corrompida

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

Suporte a O_DIRECT

O suporte a 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_DIRECT também oferece os seguintes benefícios:

O uso de O_DIRECT permite evitar 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_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 verificações sequenciais aprimoradas, ANALYZE e desempenho de pg_prewarm usando E/S vetorizada para ler vários blocos no cache de buffer. 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 do sistema.

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

Antes de começar

Verifique o sistema operacional e o suporte do sistema de arquivos.
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 do 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 do kernel que ofereça suporte a RWF_ATOMIC.

Para usar os recursos de aceleração de E/S do AlloyDB Omni para testar ganhos de performance com proteção contra gravação corrompida, ative a Grand Unified Configuration (GUC) alloydb_omni_atomic. Para usar essa GUC, é necessário ter um kernel e um sistema de arquivos compatíveis que forneçam E/S atômica e protejam contra gravações corrompidas.

A flag RWF_ATOMIC é usada para suporte a gravações atômicas. Por padrão, a compatibilidade com RWF_ATOMIC é verificada durante a inicialização. O PostgreSQL não é iniciado se as gravações atômicas com a flag RWF_ATOMIC não puderem ser confirmadas.

É 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 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 não usar essa opção, a menos que você 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 alloydb_omni_atomic e as verificações de compatibilidade correspondentes.

Valor de `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 é iniciado se a gravação `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 `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 configuração.

Configurar os 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 oferece suporte a 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, 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 operações de entrada/saída por segundo (IOPS) mais altas, 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 oferecer suporte a 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. Faça o download do contêiner do 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 de disco dentro do contêiner.
  - HOST_PORT: a postagem 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 como um valor apropriado 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 realizam E/S de bloco único, o que O_DIRECT desacelera. 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 em disco 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 performance mais baixa devido a diferenças arquitetônicas.
Devido às limitações com cargas de trabalho aumentadas, libaio é suscetível à indisponibilidade de recursos. io_uring pode apresentar problemas de alocação de memória quando a memória do sistema disponível está baixa.