Você pode decidir o limite superior do buffer compartilhado ao iniciar o AlloyDB Omni. Se você não definir o limite máximo, o AlloyDB Omni vai definir automaticamente o tamanho de backup do buffer compartilhado como 80% da memória do sistema. O tamanho inicial de suporte do buffer compartilhado pode ser diferente do limite máximo.
O AlloyDB Omni consiste em um worker de memória inteligente que monitora constantemente o status da memória e ajusta o tamanho de suporte do buffer compartilhado para melhor desempenho ao armazenar dados em cache.
Por padrão, o parâmetro shared_buffers é definido como 0, um valor especial que define o limite máximo do tamanho do cache shared buffers como 80% da memória do sistema. O AlloyDB Omni começa com 10% do limite máximo de shared_buffers. Se shared_buffers for substituído por um valor personalizado, o AlloyDB Omni vai respeitar o valor como o limite superior do tamanho de shared_buffers e começar com esse tamanho personalizado especificado.
Para especificar um tamanho personalizado, defina shared_buffers como 1GB. O método depende do tipo de implantação:
docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $imagedocker run --name CONTAINER_NAME $image -c shared_buffers=1GB
Substitua CONTAINER_NAME pelo nome que você atribuiu ao contêiner do AlloyDB Omni ao instalá-lo.
Otimizar o desempenho da consulta
O valor padrão do parâmetro shared_buffers funciona para cenários comuns.
No entanto, é possível ajustar o valor para ter o melhor desempenho.
Se você optar por usar o valor padrão de shared_buffers para deduzir o limite máximo do buffer compartilhado, use o valor memory.max do cgroup para influenciar o cálculo.
Memória do mecanismo colunar
O shared_buffers dinâmico é independente da memória do mecanismo colunar. Quando o mecanismo colunar está ativado, o tamanho dinâmico shared_buffers pode ser derivado subtraindo a quantidade de memória usada pelo mecanismo colunar de 80% da memória total disponível para o sistema ou cgroup.
Huge pages
As páginas enormes melhoram o desempenho do banco de dados. O AlloyDB Omni gerencia páginas enormes explicitamente, se possível. Caso contrário, ele usa o recurso de páginas enormes transparentes (THP, na sigla em inglês) do sistema operacional. Se nenhum dos tipos de huge page for compatível, o AlloyDB Omni vai voltar para a página de 4k e imprimir um aviso nos registros do contêiner do Dockerdocker logs $container_name com instruções específicas para configurar huge pages. Consulte Iniciar o AlloyDB Omni para instruções sobre como iniciar um contêiner.
O aviso será semelhante a este:
HINT: Please either execute the all-in-one setup script:
docker run --rm --privileged $image setup-host
OR manually execute:
echo within_size | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
sudo sysctl -w vm.nr_overcommit_hugepages=1048576
Gerenciamento automático de memória durante a execução
O AlloyDB Omni monitora constantemente a carga do sistema e ajusta o consumo de memória para melhorar o desempenho. Especificamente, você pode observar o seguinte:
- Mudança dinâmica no tamanho do
shared_buffers - O AlloyDB Omni aumenta o tamanho dinâmico do
shared_buffersquando o consumo de memória do sistema está baixo e diminui o tamanho quando o consumo de memória do sistema está alto. A extensão `g_memory` está incluída na distribuição do AlloyDB Omni. Para ativar e monitorar o tamanho dinâmico de `shared_buffers`, execute os seguintes comandos:CREATE EXTENSION IF NOT EXISTS g_memory; SELECT g_dynamic_shared_size();
- Encerramento de uma conexão do PostgreSQL quando o sistema está com pouquíssima memória
-
Quando o AlloyDB Omni detecta que o sistema está com pouquíssima memória, ele tenta excluir as conexões do PostgreSQL que consomem mais memória até que a carga volte a um nível razoável. Quando isso acontece, o AlloyDB Omni registra uma entrada semelhante ao exemplo a seguir nos registros de contêiner do Docker:
WARNING: Sending SIGTERM to pid=12345 NSpid=67890 (VA size = 1024MB) (RSS size = 512MB)