Melhore o desempenho do AlloyDB Omni com a aceleração de E/S

Selecione uma versão da documentação:

Pré-visualização — AlloyDB Omni

Esta funcionalidade está sujeita aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. Pode tratar dados pessoais para esta funcionalidade conforme descrito na Alteração ao Tratamento de Dados do Cloud, sujeito às obrigações e restrições descritas no contrato ao abrigo do qual acede ao Google Cloud. As funcionalidades de pré-DG estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Esta página descreve como ativar um conjunto de funcionalidades 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 das consultas.

Estão incluídas as seguintes funcionalidades:

Proteção contra escrita rasgada
Apoio técnico do O_DIRECT
E/S assíncrona (AIO)
Leituras em streaming

Para ativar estas funcionalidades de aceleração de E/S, ative a alloydb_omni_atomic configuração unificada geral (GUC) e configure o AlloyDB Omni para poder usar a GUC.

Funcionalidades de aceleração de E/S

As secções seguintes descrevem as funcionalidades de aceleração de E/S que a alloydb_omni_atomic GUC ativa.

Proteção contra escrita rasgada

Quando ativa a configuração do alloydb_omni_atomic, desativa as escritas de páginas completas para evitar a sobrecarga de desempenho de ter de gerar imagens de páginas completas para o registo.

Suporte de O_DIRECT

O suporte do O_DIRECT é um pré-requisito para as escritas atómicas. O_DIRECT aplica-se ao diretório de dados do PostgreSQL e à cache de disco do AlloyDB Omni. Para mais informações, consulte o artigo Acelere o desempenho da base de dados com a cache de disco.

O O_DIRECT também oferece as seguintes vantagens:

A utilização de O_DIRECT permite evitar o problema de duplicação de buffers no PostgreSQL. O PostgreSQL gere a sua própria cache de buffer e pode ignorar a cache de buffer do kernel do sistema operativo.
O_DIRECT reduz a sobrecarga de funcionamento da CPU e da memória do sistema necessárias para manter a cache do buffer do kernel.

E/S assíncrona

A configuração alloydb_omni_atomic oferece capacidades de E/S assíncronas (AIO) através das bibliotecas io_uring e libaio. Recomendamos que use io_uring para evitar as limitações da biblioteca libaio mais antiga. O AlloyDB Omni recorre ao libaio quando o suporte do io_uring não é detetado. Esta abordagem supera a perda de vantagens de E/S em buffer, como a leitura antecipada e a combinação de escrita, e também garante que a largura de banda de E/S disponível do armazenamento oferecido subjacente é maximizada.

Leituras em streaming

O AlloyDB Omni usa leituras de streaming, semelhantes à funcionalidade do PostgreSQL 17, que oferecem um desempenho melhorado das verificações sequenciais, ANALYZE e pg_prewarm, através da utilização de E/S vetorial para ler vários blocos na cache de buffer. A E/S vetorizada é um método no qual uma chamada de procedimento único pode obter previamente dados de vários buffers, o que melhora a eficiência ao reduzir as comutações de contexto e as chamadas do sistema.

O AlloyDB Omni estende o suporte para usar leituras de streaming para leituras a partir da cache de disco do AlloyDB Omni usando AIO para amplificar o desempenho de leitura. Esta abordagem facilita a leitura antecipada eficaz de buffers para o conjunto de memória partilhada a partir do armazenamento para utilização por parte das consultas, em vez de ter de ler estes blocos a partir do armazenamento sempre que são necessários.

Antes de começar

Verifique o seu sistema operativo e o suporte do sistema de ficheiros.
1. Para garantir que o kernel suporta RWF_ATOMIC, verifique a versão do kernel. No exemplo seguinte, usa uma máquina Ubuntu 24.10 com o kernel Linux 6.14 que suporta escritas atómicas.
```
> sudo hostnamectl
 ...
 Operating System: Ubuntu 24.10
      Kernel: Linux 6.14.0-061400rc5-generic
...
```
2. Se o seu kernel não tiver suporte para RWF_ATOMIC, recomendamos que atualize para uma versão do kernel que suporte RWF_ATOMIC.

Para usar as funcionalidades de aceleração de E/S do AlloyDB Omni para testar os ganhos de desempenho com a proteção contra gravação incompleta, ative a alloydb_omni_atomicconfiguração de unificação geral (GUC). Para usar este GUC, tem de ter um kernel e um sistema de ficheiros compatíveis que forneçam E/S atómica e proteção contra escritas incompletas.

A flag RWF_ATOMIC é usada para o suporte de escrita atómica. Por predefinição, a compatibilidade com o RWF_ATOMIC é verificada durante o arranque. O PostgreSQL não é iniciado se não for possível confirmar as escritas atómicas com a flag RWF_ATOMIC.

Pode substituir este comportamento predefinido, mas recomendamos que use uma plataforma suportada e a opção force para evitar substituir acidentalmente as definições de configuração ideais.

Pode ignorar a verificação de RWF_ATOMICcompatibilidade através da opçãoforce_unsafe, mas a segurança dos dados não é garantida com esta substituição. Recomendamos que não use esta opção, a menos que esteja a avaliar o AlloyDB Omni num ambiente que não possa ser atualizado para usar o kernel e o sistema de ficheiros adequados.

A tabela seguinte indica as definições de configuração da alloydb_omni_atomic e as verificações de compatibilidade correspondentes.

Valor `alloydb_omni_atomic`	Verificação de compatibilidade de arranque	Descrição
off	N/A	Este valor desativa o modo atómico. A funcionalidade está inativa.
force	Realiza a verificação de compatibilidade no arranque. Não inicia se a escrita de `RWF_ATOMIC` falhar.	Define as configurações do modo atómico.
force_unsafe	Não faz uma verificação de compatibilidade no arranque. Devolve um aviso, mas continua se a `RWF_ATOMIC` escrita 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. Pode substituir estas configurações através da configuração opcional on/on_unsafe

Configure as funcionalidades de aceleração de E/S do AlloyDB Omni

Configure o sistema de ficheiros XFS para o diretório de dados. O XFS é usado porque suporta um tamanho de bloco do sistema de ficheiros superior ao tamanho da página. O AlloyDB Omni pode usar o XFS para escrever atomicamente blocos de 8 KiB com suporte total para RWF_ATOMIC.
1. Crie um sistema de ficheiros XFS com um tamanho de bloco de 8 KiB e monte-o na localização do diretório de dados pretendida (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: a localização do diretório de dados.
2. Verifique os registos do kernel para garantir que são usados blocos de 8k:
```
> 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 a cache de disco do AlloyDB Omni.

Use o exemplo seguinte para criar um sistema de ficheiros com ext4, e, em seguida, montar o sistema de ficheiros.
```
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 a qual a aplicação interage para realizar operações de E/S (leitura ou gravação de dados).
Para suportar o desempenho ideal das funcionalidades de aceleração de E/S do AlloyDB Omni quando o armazenamento principal não oferece um número mais elevado de operações de entrada/saída por segundo (IOPS), recomendamos que configure a cache de disco do AlloyDB Omni. Para mais informações, consulte o artigo Acelere o desempenho da base de dados com a cache de disco.

Nota: a cache de disco não tem de suportar escritas atómicas porque os dados na cache são efémeros. No entanto, as funcionalidades de aceleração de E/S do AlloyDB Omni continuam a usar o O_DIRECT para aceder à cache.
Transfira e execute o AlloyDB Omni.
1. Transfira o contentor do Docker do AlloyDB Omni mais recente. Para mais informações, consulte o artigo Instale o AlloyDB Omni numa VM.
2. Para usar a cache de disco, siga as instruções em Acelere o desempenho da base de dados com a cache de disco.
3. Para permitir io_uring, adicione um argumento adicional, --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 contentor do AlloyDB Omni no registo de contentores da sua máquina anfitriã.
  - NEW_PASSWORD: a palavra-passe atribuída ao utilizador do PostgreSQL do contentor.
  - DATA_DIR: a localização do diretório de dados.
  - CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: o caminho do diretório da cache de disco no contentor.
  - HOST_PORT: a porta TCP na máquina anfitriã para a qual o contentor deve publicar a sua própria porta 5432.
Configure o AlloyDB Omni para usar E/S atómica.

Defina o alloydb_omni_atomic GUC para um valor adequado e reinicie o contentor.
```
alter system set alloydb_omni_atomic='force';
sudo docker restart CONTAINER_NAME;
```
Faça as seguintes substituições:
- CONTAINER_NAME: o nome do contentor do AlloyDB Omni no registo de contentores da sua máquina anfitriã.

Limitações

O PostgreSQL 16 contém caminhos que executam E/S de bloco único, o que O_DIRECT abranda o processo. Pode haver leituras mais lentas durante a recuperação da base de dados (caminho de repetição), as análises de limpeza e o pré-aquecimento da cache de disco Omni.
As funcionalidades de aceleração de E/S do AlloyDB Omni em réplicas de leitura não são suportadas na pré-visualização.
Em cargas de trabalho elevadas, os sistemas baseados em ARM podem apresentar um desempenho inferior devido a diferenças arquitetónicas.
Devido às suas limitações com cargas de trabalho aumentadas, o libaio é suscetível à indisponibilidade de recursos. io_uring pode ter problemas de atribuição de memória quando a memória do sistema disponível está a ficar baixa.