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.

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 de recursos de computação e E/S para cargas de trabalho e desempenho de consulta mais rápidos.

Os seguintes recursos estão incluídos:

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

Para ativar esses recursos de aceleração de E/S, ative a alloydb_omni_atomic Grand Unified Configuration (GUC) 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 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 geração de registros.

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 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 O_DIRECT reduz a operação da CPU do sistema e o overhead de memória necessários para manter o cache do buffer do kernel.

E/S assíncrona

A configuração alloydb_omni_atomic oferece recursos de E/S assíncrona (AIO, na sigla em inglês) usando as bibliotecas io_uring e libaio. Recomendamos que você use 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, além de garantir 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 melhoram o desempenho de verificações sequenciais, ANALYZE e pg_prewarm usando E/S vetorizada para ler vários blocos no cache do buffer. A E/S vetorial é 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 o desempenho de leitura. Essa abordagem facilita a leitura antecipada de buffers no pool de memória compartilhada do armazenamento para que as consultas sejam usadas, em vez de ler esses blocos do armazenamento sempre que forem 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 que executa 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 for compatível com RWF_ATOMIC, recomendamos que você atualize para uma versão do kernel compatível com RWF_ATOMIC.

Para usar os recursos de aceleração de E/S do AlloyDB Omni para testar os ganhos de desempenho com a proteção contra gravação corrompida, ative a alloydb_omni_atomic Grand Unification Configuration (GUC). Para usar esse 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 à gravação atômica. Por padrão, a compatibilidade com RWF_ATOMIC é verificada durante a inicialização. O PostgreSQL não será iniciado se as gravações atômicas com a flag RWF_ATOMIC não puderem ser confirmadas.

É possível modificar esse comportamento padrão, mas recomendamos que você use uma plataforma compatível e a opção force para evitar a modificação acidental das configurações ideais.

É possível substituir a RWF_ATOMICverificação de compatibilidade 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 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. Falha ao 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 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 é compatível com 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 total 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 desejado (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 os 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, 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 garantir o 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 que você configure 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 do AlloyDB Omni mais recente. 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êiner 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 do cache em 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 o 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êiner da máquina host.

Limitações

O PostgreSQL 17 contém caminhos que realizam E/S de bloco único, o que desacelera o O_DIRECT. 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 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 menor desempenho devido a diferenças de arquitetura.
Devido às limitações com o aumento das cargas de trabalho, o libaio está suscetível à 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.