AlloyDB Omni utilizza algoritmi adattivi per la gestione della memoria.
Puoi decidere il limite superiore del buffer condiviso all'avvio di AlloyDB Omni. Se non imposti il limite superiore, AlloyDB Omni imposta automaticamente le dimensioni del backup del buffer condiviso all'80% della memoria di sistema. Le dimensioni iniziali del backup del buffer condiviso possono essere diverse dal limite superiore.
AlloyDB Omni è costituito da un worker di memoria intelligente che monitora costantemente lo stato della memoria e ottimizza le dimensioni del backup del buffer condiviso per ottenere le migliori prestazioni durante la memorizzazione nella cache dei dati.
Per impostazione predefinita, il parametro shared_buffers
è impostato su 0
, un valore speciale che imposta il limite superiore delle dimensioni della cache shared buffers
sull'80% della memoria di sistema. AlloyDB Omni inizia dal 10% del limite superiore shared_buffers
. Se shared_buffers
viene sostituito da un valore personalizzato, AlloyDB Omni rispetta il valore come limite superiore della dimensione shared_buffers
e inizia con la dimensione personalizzata specificata.
Per specificare una dimensione personalizzata, modifica il file di configurazione postgresql.conf
. Ad esempio, puoi impostare shared_buffers
su 1GB
utilizzando una delle seguenti opzioni:
docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $image
docker run --name CONTAINER_NAME $image -c shared_buffers=1GB
Sostituisci
CONTAINER_NAME
con il nome assegnato al contenitore AlloyDB Omni durante l'installazione.
Ottimizzare le prestazioni delle query
Il valore predefinito del parametro shared_buffers
è valido per gli scenari comuni.
Tuttavia, puoi ottimizzare il valore per ottenere il rendimento migliore.
Se scegli di fare affidamento sul valore predefinito shared_buffers
per dedurre il limite superiore del buffer condiviso, utilizza il valore memory.max
del cgroup per influenzare il calcolo.
Memoria del motore colonnare
Il shared_buffers
dinamico è indipendente dalla memoria del motore colonnare. Quando il motore colonnare è abilitato, le dimensioni dinamiche di shared_buffers
possono essere ricavate sottraendo la quantità di memoria utilizzata dal motore colonnare dall'80% della memoria totale disponibile per il sistema o il cgroup.
Huge page
Le pagine enormi migliorano le prestazioni del database. AlloyDB Omni gestisce le pagine enormi in modo esplicito, se possibile, altrimenti si basa sulla funzionalità THP (Transparent Huge Pages) del sistema operativo. Se nessuno dei due tipi di pagine enormi è supportato, AlloyDB Omni torna alla pagina 4K e stampa un avviso nei log del contenitore Docker docker logs $container_name
con istruzioni specifiche per configurare le pagine enormi. Per istruzioni su come avviare un contenitore, consulta Avvia AlloyDB Omni.
L'avviso è simile al seguente:
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
Gestione automatica della memoria in fase di esecuzione
AlloyDB Omni monitora costantemente il carico del sistema e regola il consumo di memoria per migliorare le prestazioni. Nello specifico, potresti notare quanto segue:
- Modifica dinamica delle dimensioni
shared_buffers
- AlloyDB Omni aumenta le dimensioni dinamiche
shared_buffers
quando il consumo di memoria di sistema è basso e le riduce quando è elevato. Per monitorare la dimensione dinamicashared_buffers
, utilizza:CREATE EXTENSION IF NOT EXISTS g_memory; SELECT g_dynamic_shared_size();
- Terminazione di una connessione PostgreSQL quando la memoria del sistema è estremamente ridotta
- Quando AlloyDB Omni rileva che la memoria del sistema è estremamente ridotta, tenta di eliminare le connessioni PostgreSQL che consumano più memoria finché il carico non torna a un livello ragionevole. Quando si verifica un evento di questo tipo, AlloyDB Omni registra quanto segue nei log del contenitore Docker:
WARNING: Sending SIGTERM to pid=xxx NSpid=xxx (VA size = xxxMB) (RSS size = xxxMB)