Best practice per la gestione dell'utilizzo della memoria

Questa pagina descrive come configurare l'utilizzo della memoria per un'istanza Cloud SQL.

Introduzione

Quando crei un'istanza Cloud SQL, selezioni una quantità di memoria per l'istanza. Con l'aumento del carico di lavoro di un database PostgreSQL, aumenta anche l'utilizzo della memoria dell'istanza. Le istanze che consumano molta memoria possono creare un collo di bottiglia delle prestazioni che a volte può portare a problemi di esaurimento della memoria.

Quando un'istanza Cloud SQL esaurisce la memoria a causa di un aumento della domanda, può verificarsi un tempo di inattività del database. Pertanto, è importante configurare correttamente la memoria dell'istanza e gli indicatori del database relativi alla memoria e monitorare l'utilizzo della memoria in modo che l'istanza funzioni in uno stato corretto.

I componenti della memoria PostgreSQL sono suddivisi in due sezioni:

  • Memoria globale:è condivisa tra tutti i processi per l'esecuzione delle query, ad esempio shared_buffers e max_connections.
  • Memoria locale: si tratta di memoria dedicata assegnata a ogni connessione, ad esempio work_mem, maintenance_work_mem e temp_buffers.

Per altre considerazioni sulla configurazione, consulta le best practice generali e le linee guida operative.

Utilizzo della memoria e flag

Ogni volta che le istanze Cloud SQL utilizzano molta memoria, potrebbero sorgere le seguenti domande:

  • Quale query o processo utilizza molta memoria?
  • Le impostazioni di memoria sono adeguate per l'attività del database?
  • Come faccio a modificare le impostazioni della memoria?

Quando un database PostgreSQL è in funzione, la maggior parte dell'utilizzo della memoria si verifica in alcune aree:

  • Buffer condiviso: si tratta della memoria condivisa che PostgreSQL alloca per memorizzare i dati delle tabelle per le operazioni read e write. Per l'operazione read, tutti i dati richiesti dal disco vengono prima recuperati nella RAM e poi dati al client. Analogamente, in PostgreSQL, quando i dati vengono richiesti (ad esempio SELECT * from emp), vengono prima recuperati dal disco in shared_buffers per la memorizzazione nella cache e poi vengono dati al client. Lo stesso accade con l'operazione write.

    Il buffer condiviso è anche l'area di memoria condivisa per tutte le attività del database, come la memorizzazione nella cache dei dati, la memorizzazione nella cache delle connessioni e le operazioni di Data Manipulation Language (DML). Il valore massimo che questa area può allocare è specificato dal flag shared_buffers e il valore predefinito è il 33% della memoria dell'istanza. Se il valore di shared_buffers è elevato, le dimensioni dei dati memorizzati nella cache in memoria sono elevate.

  • Memoria di lavoro delle query: durante l'esecuzione di una query, PostgreSQL alloca memoria locale per ogni operazione, come ordinamento e hashing. Il valore massimo che può essere allocato per ogni operazione di una query prima della scrittura nei file di disco temporanei è configurato dal flag work_mem e il valore predefinito è 4 MB. Se il valore di work_mem è elevato, la quantità di dati che può essere ordinata nella memoria è elevata.
  • Memoria per i lavori di manutenzione: alcune operazioni di manutenzione come VACUUM, CREATE INDEX, ALTER TABLE e ADD FOREIGN KEY richiedono memoria locale separata allocata da PostgreSQL. La quantità massima per il processo di backend utilizzato da queste operazioni può essere configurata tramite il flag maintenance_work_mem e il valore predefinito è 64 MB. Tieni presente che i worker autovacuum utilizzano anche la memoria per i lavori di manutenzione e il valore massimo può essere ignorato dal flag autovacuum_work_mem. Se il valore di maintenance_work_mem è elevato, la velocità di esecuzione dell'operazione VACUUM è elevata.
  • Buffer temporanei: quando una tabella temporanea viene utilizzata in una sessione del database, PostgreSQL alloca buffer temporanei per contenere la tabella temporanea locale della sessione. L'importo massimo può essere specificato tramite il flag temp_buffers e il valore predefinito è 8 MB.
  • Connessione al database:quando un client si connette al database, PostgreSQL crea un processo di backend per gestire la sessione del client. Oltre alla memoria per eseguire la query, PostgreSQL alloca memoria aggiuntiva per gestire informazioni come la cache del catalogo di sistema e i piani di query preparati. Il numero massimo di connessioni simultanee consentite al server di database può essere configurato tramite il flag max_connections. Ogni connessione inattiva utilizza circa 2-3 MB di memoria condivisa. Se il valore di max_connections è elevato, l'istanza può effettuare più connessioni, ma a scapito della memoria.

Per l'elenco completo dei componenti della memoria in PostgreSQL, consulta la documentazione di PostgreSQL. Per modificare i flag elencati in questa sezione, vedi Configurare i flag di database.

Monitorare l'utilizzo della memoria

Monitora regolarmente la memoria dell'istanza in Cloud Monitoring e mantienila al di sotto del limite di memoria. Una buona prassi consiste nell'impostare un avviso in Cloud Monitoring per ricevere un avviso quando l'utilizzo supera il 90% del limite per 6 ore. Questo avviso può avvisarti quando l'utilizzo della memoria è costantemente vicino al limite.

Inoltre, monitora la presenza di incidenti di esaurimento memoria. Per farlo, configura una metrica basata su log per il messaggio server process .* was terminated by signal 9: Killed in Cloud Monitoring per conteggiare gli eventi di esaurimento della memoria e poi invia un avviso ogni volta che si verifica un evento di questo tipo.

Se l'istanza funziona costantemente al di sopra del 90% del limite di memoria o si verifica un evento di esaurimento della memoria, puoi aumentare la memoria dell'istanza. In alternativa, puoi ridurre l'utilizzo della memoria limitando il numero di connessioni al database o abbassando i flag del database come shared_buffers, work_mem o max_connections. L'abbassamento di questi parametri può limitare le prestazioni dell'istanza.

Memoria insufficiente

Quando la memoria non è sufficiente per gestire il carico di lavoro del database, come ultima risorsa, il sistema operativo Linux di base utilizza out-of-memory (OOM) killer per terminare un processo e liberare memoria. Cloud SQL è configurato in modo che OOM killer abbia come target solo i processi worker PostgreSQL. In questa situazione, il processo postmaster viene conservato in modo da dover solo terminare tutte le connessioni al database esistenti ed eseguire un recupero per proteggere l'integrità del database. In questo caso, si verificano interruzioni del servizio e tempi di inattività del database. Nel log del database PostgreSQL vengono visualizzati messaggi come i seguenti:

2021-10-24 23:34:22.265 UTC [7]: [663-1] db=,user= LOG: server process (PID 1255039) was terminated by signal 9: Killed
2021-10-24 23:34:22.265 UTC [7]: [664-1] db=,user= DETAIL: Failed process was running: SELECT * FROM tab ORDER BY col
2021-10-24 23:34:22.277 UTC [7]: [665-1] db=,user= LOG: terminating any other active server processes
2021-10-24 23:34:22.278 UTC [1255458]: [1-1] db=postgres,user=postgres WARNING: terminating connection because of crash of another server process
2021-10-24 23:34:22.278 UTC [1255458]: [2-1] db=postgres,user=postgres DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-10-24 23:34:22.278 UTC [1255458]: [3-1] db=postgres,user=postgres HINT: In a moment you should be able to reconnect to the database and repeat your command.
2021-10-24 23:34:22.278 UTC [1255458]: [4-1] db=postgres,user=postgres CONTEXT: while updating tuple (27,18) in relation "tab"
...
2021-10-24 23:34:22.558 UTC [1255477]: [1-1] db=postgres,user=postgres FATAL: the database system is in recovery mode
...
2021-10-24 23:34:25.579 UTC [7]: [666-1] db=,user= LOG: all server processes terminated; reinitializing
...
2021-10-24 23:34:25.691 UTC [1255482]: [1-1] db=,user= LOG: database system was interrupted; last known up at 2021-10-24 23:31:53 UTC
2021-10-24 23:34:25.776 UTC [1255482]: [2-1] db=,user= LOG: database system was not properly shut down; automatic recovery in progress
2021-10-24 23:34:25.789 UTC [1255482]: [3-1] db=,user= LOG: redo starts at 227/AB359400
2021-10-24 23:34:38.957 UTC [1255482]: [4-1] db=,user= LOG: redo done at 229/4621F508
2021-10-24 23:34:38.959 UTC [1255482]: [5-1] db=,user= LOG: last completed transaction was at log time 2021-10-24 23:34:18.5535+00
2021-10-24 23:34:39.290 UTC [7]: [667-1] db=,user= LOG: database system is ready to accept connections

Passaggi successivi