Questo documento spiega come identificare un utilizzo elevato della memoria per le istanze Cloud SQL e fornisce consigli su come risolvere i problemi relativi alla memoria.
Per scoprire come configurare l'utilizzo della memoria per un'istanza Cloud SQL, vedi Best practice per la gestione della memoria utilizzata.
Identificazione di un utilizzo elevato della memoria
Usa Esplora metriche per identificare l'utilizzo della memoria
Puoi rivedere l'utilizzo della memoria dell'istanza con
Metrica database/memory/components.usage
in
Esplora metriche.
Utilizza Approfondimenti sulle query per analizzare il piano di spiegazione per le query che consumano molte risorse
Query Insights ti aiuta a rilevare, diagnosticare e prevenire i problemi di prestazioni delle query per i database Cloud SQL. Query Insights fornisce un elenco di query in esecuzione prolungata e il relativo piano di spiegazione (documentazione PostgreSQL). Rivedi il piano di spiegazione e identifica la parte della query con un metodo di analisi che prevede un utilizzo elevato della memoria. Indipendentemente dal tempo di esecuzione della query, Query Insights fornisce il piano di spiegazione per tutte le query. Identifica le query complesse che richiedono più tempo, in modo da sapere quali query bloccano la memoria per periodi più lunghi.
I metodi di scansione PostgreSQL comuni che utilizzano molta memoria includono:
- Scansione heap bitmap
- Ordinamento rapido
- Hash join o Hash
Utilizzo elevato della memoria e log pertinenti per le istanze con Gemini abilitato
Se hai abilitato Gemini, invece di un errore di esaurimento della memoria (OOM) che comporta un tempo di inattività del database, una connessione che esegue una query con utilizzo elevato di memoria viene terminata, impedendo così il tempo di inattività del database. Per identificare la query predefinita, puoi controllare nei log del database le seguenti voci:
(...timestamp….) db=postgres, user=customer FATAL: terminating connection due to administrator command
Viene visualizzato il seguente log del database Cloud SQL per PostgreSQL che acquisisce la query con utilizzo elevato della memoria che è stata interrotta per evitare OOM. La query è una versione normalizzata della query originale:
db=postgres,user=customer LOG: postgres process with PID 1734 for the query "SELECT COUNT(product) AS item_count FROM test_table WHERE product_type = $1 AND product LIKE $2 AND c6_2 IN ($3,$4,$5,$6,$7)" has been cancelled.
Le notifiche vengono visualizzate anche nella pagina Istanze Cloud SQL per i seguenti eventi:
- Utilizzo della memoria dell'istanza nelle ultime 24 ore.
- Elenco delle query normalizzate che sono state annullate nelle ultime 24 ore.
- Un link alla documentazione di Google sull'ottimizzazione della memoria utilizzata.
Utilizzo elevato della memoria - Suggerimenti
I seguenti consigli riguardano i problemi comuni relativi alla memoria.
Se l'istanza continua a utilizzare una quantità elevata di memoria, è probabile che alla fine si verifichi un problema di out of memory
.
Se le richieste di memoria di PostgreSQL o di un altro processo causano la mancanza di memoria nel sistema, viene visualizzato un messaggio del kernel Out of Memory
nei log di PostgreSQL e l'istanza PostgreSQL viene interrotta.
Ad esempio:
Out of Memory: Killed process 12345 (postgres)
L'istanza più comune in cui si verifica un problema di esaurimento della memoria è con un valore più elevato di work_mem
con un numero elevato di connessioni attive.
Di conseguenza, se ricevi frequenti OOM o vuoi evitarli nell'istanza Cloud SQL per PostgreSQL, ti consigliamo di seguire questi suggerimenti:
Imposta
work_mem
Le query che utilizzano la ricerca rapida sono più veloci di quelle che utilizzano la ricerca combinata esterna. Tuttavia, la prima potrebbe comportare l'esaurimento della memoria. Per risolvere il problema, imposta un valore
work_mem
sufficientemente ragionevole in modo da bilanciare le operazioni di ordinamento nella memoria e sul disco. Puoi anche valutare la possibilità di impostarework_mem
a livello di sessione anziché per un'intera istanza.Monitora le sessioni attive
Ogni connessione utilizza una determinata quantità di memoria. Utilizza la seguente query per controllare il numero di connessioni attive:
SELECT state, usename, count(1) FROM pg_stat_activity WHERE pid <> pg_backend_pid() GROUP BY state, usename ORDER BY 1;
Se hai un numero elevato di sessioni attive, analizza la causa principale di questo fenomeno, ad esempio i blocchi delle transazioni.
Imposta
shared_buffers
Se il criterio
shared_buffers
è impostato su un valore superiore, ti consigliamo di diminuire il valore dishared_buffers
in modo che la memoria possa essere utilizzata per altre operazioni, ad esempiowork_mem
, o per stabilire nuove connessioni.Percentuale di successi della cache
In genere, PostgreSQL tenta di mantenere nella cache i dati a cui accedi più di frequente. Quando i dati vengono richiesti da un cliente, Se è già memorizzato nella cache in buffer condivisi, viene fornito direttamente al client. In tal caso si parla di successo della cache. Se non sono presenti nei buffer condivisi, vengono prima recuperati da un disco e poi inviati al client. In tal caso si parla di fallimento della cache. Il rapporto di successi della cache misura il numero di richieste di contenuto gestite dalla cache rispetto alle richieste ricevute. Esegui la seguente query per controllare il rapporto di hit della cache per le richieste di tabelle nell'istanza PostgreSQL:
SELECT sum(heap_blks_read) as heap_read, sum(heap_blks_hit) as heap_hit, sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as ratio FROM pg_statio_user_tables;
Esegui questa query per controllare il percentuale successi cache per le richieste di indice nell'istanza PostgreSQL:
SELECT sum(idx_blks_read) as idx_read, sum(idx_blks_hit) as idx_hit, (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as ratio FROM pg_statio_user_indexes;
In genere, una percentuale di successi della cache compresa tra 95 e 99% è considerata un buon valore.
Abilita pagine di grandi dimensioni Per impostazione predefinita, Cloud SQL per PostgreSQL ha
huge_pages
abilitato per una migliore gestione della memoria. Ti consigliamo di abilitarlo. Per scoprire di più suhuge_pages
, consulta la documentazione di PostreSQL.Imposta
max_locks_per_transaction
Il valore
max_locks_per_transaction
indica il numero di oggetti del database che possono essere bloccati contemporaneamente. Nella maggior parte dei casi, il valore predefinito 64 è sufficiente. Tuttavia, se hai a che fare con un set di dati di grandi dimensioni, potresti finire per avere degli OOM. Valuta la possibilità di aumentare il valore dimax_locks_per_transaction
sufficientemente alta da evitare OOM.Il valore
max_locks_per_transaction
deve esseremax_locks_per_transaction
* (max_connections
+max_prepared_transactions
) oggetti. Ciò significa che se hai 300 mila oggetti e il valore dimax_connections
è 200,max_locks_per_transaction
deve essere 1500.Imposta
max_pred_locks_per_transaction
La transazione potrebbe non riuscire se hai client che toccano molte tabelle diverse in un'unica transazione serializzabile. In questo caso, ti consigliamo di aumentare
max_pred_locks_per_transaction
a un valore ragionevolmente elevato. Comemax_locks_per_transaction
, anchemax_pred_locks_per_transaction
utilizza la memoria condivisa, quindi non impostare un valore eccessivamente elevato.Se l'utilizzo della memoria è ancora elevato e ritieni che le query siano traffico legittimo, valuta la possibilità di aumentare il numero di risorse di memoria nell'istanza per evitare arresti anomali o tempi di inattività del database.