Pode decidir o limite superior da memória intermédia partilhada ao iniciar o AlloyDB Omni. Se não definir o limite superior, o AlloyDB Omni define automaticamente o tamanho de apoio da memória intermédia partilhada como 80% da memória do sistema. O tamanho inicial da cópia de segurança do buffer partilhado pode ser diferente do limite superior.
O AlloyDB Omni consiste num worker de memória inteligente que monitoriza constantemente o estado da memória e ajusta o tamanho da cópia de segurança do buffer partilhado para um melhor desempenho ao colocar dados em cache.
Por predefinição, o parâmetro shared_buffers está definido como 0, que é um valor especial que define o limite superior do tamanho da cache shared buffers para 80% da memória do sistema. O AlloyDB Omni começa com 10% do limite superior de shared_buffers. Se shared_buffers for substituído por um valor personalizado, o AlloyDB Omni respeita o valor como o limite superior do tamanho de shared_buffers e começa com esse tamanho personalizado especificado.
Para especificar um tamanho personalizado, edite o ficheiro de configuração postgresql.conf. Por exemplo, pode definir shared_buffers como 1GB através de qualquer uma das seguintes opções:
docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $imagedocker run --name CONTAINER_NAME $image -c shared_buffers=1GBSubstitua
CONTAINER_NAMEpelo nome que atribuiu ao contentor do AlloyDB Omni quando o instalou.
Otimize o desempenho das consultas
O valor predefinido do parâmetro shared_buffers funciona para cenários comuns.
No entanto, pode ajustar o valor para ter o melhor desempenho.
Se optar por basear-se no valor predefinido de shared_buffers para deduzir o limite superior do buffer partilhado, use o valor memory.max do cgroup para influenciar o cálculo.
Memória do motor colunar
O shared_buffers dinâmico é independente da memória do motor de colunas. Quando o motor de colunas está ativado, o tamanho shared_buffers dinâmico pode ser obtido subtraindo a quantidade de memória usada pelo motor de colunas a 80% da memória total disponível para o sistema ou o cgroup.
Páginas enormes
As páginas enormes melhoram o desempenho da base de dados. O AlloyDB Omni gere páginas grandes explicitamente, se possível. Caso contrário, depende da funcionalidade de páginas grandes transparentes (THP) do sistema operativo. Se nenhum dos tipos de páginas grandes for suportado, o AlloyDB Omni recorre a uma página de 4k e imprime um aviso nos registos do contentor Docker docker logs $container_name com instruções específicas para configurar páginas grandes. Consulte o artigo Inicie o AlloyDB Omni para ver instruções sobre como iniciar um contentor.
O aviso tem um aspeto semelhante ao seguinte:
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
Gestão automática de memória no tempo de execução
O AlloyDB Omni monitoriza constantemente a carga do sistema e ajusta os respetivos consumos de memória para um melhor desempenho. Especificamente, pode observar o seguinte:
- Alteração dinâmica do tamanho do
shared_buffers - O AlloyDB Omni aumenta o tamanho dinâmico
shared_buffersquando o consumo de memória do sistema é baixo e diminui o tamanho quando o consumo de memória do sistema é elevado. Para monitorizar o tamanhoshared_buffersdinâmico, use:CREATE EXTENSION IF NOT EXISTS g_memory; SELECT g_dynamic_shared_size();
- Rescisão de uma ligação PostgreSQL quando o sistema tem muito pouca memória
- Quando o AlloyDB Omni deteta que o sistema tem muito pouca memória, tenta eliminar as ligações PostgreSQL que consomem mais memória até que a carga volte a um nível razoável. Quando ocorre um evento deste tipo, o AlloyDB Omni regista o seguinte nos registos do contentor Docker:
WARNING: Sending SIGTERM to pid=xxx NSpid=xxx (VA size = xxxMB) (RSS size = xxxMB)