Sobre o gerenciamento automático de memória

O AlloyDB Omni usa algoritmos adaptáveis para gerenciamento de memória.

Você pode definir o limite máximo 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 do backup do buffer compartilhado como 80% da memória do sistema. O tamanho inicial de backup 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 do backup do buffer compartilhado para melhor desempenho ao armazenar dados em cache.

Memória automática

Por padrão, o parâmetro shared_buffers é definido como 0, que é um valor especial que define o limite superior do tamanho do cache shared buffers como 80% da memória do sistema. O AlloyDB Omni começa em 10% do limite superior 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 shared_buffers e começar com esse tamanho personalizado especificado.

Para especificar um tamanho personalizado, edite o arquivo de configuração postgresql.conf. Por exemplo, é possível definir shared_buffers como 1GB usando uma das seguintes opções:

  • docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $image

  • docker run --name CONTAINER_NAME $image -c shared_buffers=1GB

    Substitua CONTAINER_NAME pelo nome que você atribuiu ao contêiner AlloyDB Omni quando ele foi instalado.

Otimizar a performance 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 a melhor performance. Se você optar por usar o valor padrão de shared_buffers para deduzir o limite máximo do buffer compartilhado, use o valor cgroup memory.max 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 de colunas está ativado, o tamanho dinâmico de shared_buffers pode ser derivado subtraindo a quantidade de memória usada pelo mecanismo de colunas de 80% da memória total disponível para o sistema ou cgroup.

Páginas enormes

As páginas enormes melhoram o desempenho do banco de dados. O AlloyDB Omni gerencia páginas grandes explicitamente, se possível. Caso contrário, ele depende do recurso de páginas grandes transparentes (THP, na sigla em inglês) do sistema operacional. Se nenhum tipo de página enorme for aceito, o AlloyDB Omni vai usar a página de 4k e vai mostrar um aviso nos registros do contêiner do Docker docker logs $container_name com instruções específicas para configurar páginas enormes. Consulte Iniciar o AlloyDB Omni para instruções sobre como iniciar um contêiner.

O aviso é 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 no momento da 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 de tamanho do shared_buffers
O AlloyDB Omni aumenta o tamanho dinâmico do shared_buffers quando o consumo de memória do sistema é baixo e diminui o tamanho quando o consumo de memória do sistema é alto. Para monitorar o tamanho dinâmico do shared_buffers, use: 
CREATE EXTENSION IF NOT EXISTS g_memory;
SELECT g_dynamic_shared_size();
Encerramento de uma conexão do PostgreSQL quando o sistema está com pouca memória
Quando o AlloyDB Omni detecta que o sistema está com pouca 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 o seguinte nos registros do contêiner do Docker: 
WARNING: Sending SIGTERM to pid=xxx NSpid=xxx (VA size = xxxMB) (RSS size = xxxMB)