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, la memoria utilizzata dall'istanza aumenta. Le istanze che consumano molta memoria possono 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, il database potrebbe subire tempi di inattività. 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 di memoria PostgreSQL sono generalmente 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 della 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.

Memoria utilizzata e flag

Ogni volta che si verifica un utilizzo elevato della memoria da parte delle istanze Cloud SQL, potrebbero sorgere domande:

  • Quale query o processo utilizza memoria elevata?
  • Le impostazioni della memoria sono adeguate per l'attività del database?
  • Come si modificano le impostazioni della memoria?

Quando funziona un database PostgreSQL, la maggior parte della memoria viene utilizzata 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 vengono 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 numero massimo consentito per quest'area alloca è 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 è alto, la quantità di dati che possono essere ordinati in memoria è elevata.
  • Memoria lavoro di manutenzione: alcune operazioni di manutenzione come VACUUM, CREATE INDEX, ALTER TABLE e ADD FOREIGN KEY richiede memoria locale separata allocata da PostgreSQL. L'importo massimo per il processo di backend utilizzato da queste operazioni può essere configurato dal 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 in un database viene utilizzata una tabella temporanea sessione, PostgreSQL alloca buffer temporanei per contenere il percorso tabella temporanea. 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 al memoria per eseguire la query, PostgreSQL alloca ulteriore memoria gestire informazioni quali la cache del catalogo di sistema e i piani di query preparati. La il numero massimo di connessioni simultanee consentite al server di database può essere configurato 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, consulta Configurare i flag di database.

Monitorare l'utilizzo della memoria

Monitora la memoria dell'istanza in Cloud Monitoring regolarmente e mantienilo al di sotto del limite di memoria. Una buona pratica è impostare un avviso in Cloud Monitoring per ricevere un avviso quando l'utilizzo supera il 90% del limite per 6 nell'orario lavorativo locale del TAM. 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 server process .* was terminated by signal 9: Killed in Cloud Monitoring per conteggiare gli eventi di esaurimento della memoria e ricevere 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 esaurita

Se non c'è memoria sufficiente per gestire il carico di lavoro del database, come ultima risorsa, il sistema operativo Linux sottostante utilizza out-of-memory (OOM) killer per terminare un processo per 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. Se accade, ci sono momenti in cui interruzioni del servizio e tempi di inattività per il 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