Ottimizza l'utilizzo elevato di memoria nelle istanze

Questo documento spiega come identificare la memoria utilizzata elevata per le istanze Cloud SQL e fornisce suggerimenti su come risolvere i problemi relativi alla memoria.

Per scoprire come configurare la memoria utilizzata per un'istanza Cloud SQL, consulta Best practice per la gestione della memoria utilizzata.

Identificare la memoria utilizzata elevata

Le sezioni seguenti descrivono gli scenari di memoria utilizzata elevata.

Utilizzare Esplora metriche per identificare la memoria utilizzata

Puoi esaminare la memoria utilizzata dell'istanza con la database/memory/components.usage metrica in Esplora metriche.

Utilizzare Query Insights per analizzare il piano di spiegazione delle query che consumano molte risorse

Query Insights consente di rilevare, diagnosticare e prevenire i problemi di prestazioni delle query per i database Cloud SQL. Query Insights fornisce un elenco di query a esecuzione prolungata insieme al relativo piano di spiegazione (documentazione di PostgreSQL). Esamina il piano di spiegazione e identifica la parte della query con un metodo di scansione con 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 per sapere quali query bloccano la memoria per periodi di tempo più lunghi.

I metodi di scansione PostgreSQL comuni che utilizzano una quantità elevata di memoria includono:

  • Scansione dell'heap bitmap
  • Ordinamento rapido
  • Unione hash o hash

Utilizzo elevato della memoria utilizzata e log pertinenti per le istanze abilitate a Gemini

Se hai attivato Gemini, anziché un errore OOM che comporta tempi di inattività del database, una connessione che esegue una query con un utilizzo elevato della memoria viene terminata, evitando così tempi di inattività del database. Per identificare la query predefinita, puoi controllare le seguenti voci nei log del database:

  (...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 un utilizzo elevato della memoria utilizzata che è stata terminata 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: consigli

I seguenti consigli riguardano i problemi comuni relativi alla memoria. Se l'istanza continua a utilizzare una quantità elevata di memoria, è molto probabile che si verifichi un problema di out of memory. Se le richieste di memoria di PostgreSQL o di un altro processo causano un out of memory del sistema, nei log di PostgreSQL viene visualizzato un messaggio del kernel Out of Memory e l'istanza PostgreSQL viene infine arrestata. Ad esempio:

Out of Memory: Killed process 12345 (postgres)

L'istanza più comune in cui si verifica un problema OOM è quella con un valore più alto di work_mem con un numero elevato di connessioni attive. Pertanto, se si verificano OOM frequenti o per evitarli nell'istanza Cloud SQL per PostgreSQL, ti consigliamo di seguire questi consigli:

  • Imposta work_mem

    Le query che utilizzano l'ordinamento rapido sono più veloci di quelle che utilizzano l'ordinamento di unione esterno. Tuttavia, le prime potrebbero causare l'esaurimento della memoria. Per risolvere il problema, imposta il valore work_mem in modo ragionevole in modo da bilanciare sia le operazioni di ordinamento che avvengono in memoria sia quelle su disco. Puoi anche prendere in considerazione l'impostazione di work_mem a livello di sessione anziché per l'intera istanza.

  • Monitora le sessioni attive

    Ogni connessione utilizza una certa 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 un numero elevato di sessioni attive, ad esempio i blocchi delle transazioni.

  • Imposta shared_buffers

    Se shared_buffers è impostato su un valore più alto, valuta la possibilità di diminuire il valore di shared_buffers in modo che la memoria possa essere utilizzata per altre operazioni, come work_mem, o per stabilire nuove connessioni.

    Percentuale successi cache

    In genere, PostgreSQL tenta di conservare nella cache i dati a cui accedi più spesso. Quando i dati vengono richiesti da un client, se sono già memorizzati nella cache nei buffer condivisi, vengono forniti direttamente al client. In tal caso si parla di successo della cache. Se i dati non sono presenti nei buffer condivisi, vengono prima recuperati nei buffer condivisi da un disco e poi forniti al client. In tal caso si parla di fallimento della cache. La percentuale successi cache misura il numero di richieste di contenuti gestite dalla cache rispetto alle richieste ricevute. Esegui la seguente query per controllare la percentuale successi 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 la seguente query per controllare la percentuale successi cache per le richieste di indici 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 successi cache compresa tra il 95 e il 99% è considerata un buon valore.

  • In Cloud SQL per PostgreSQL, il flag huge_pages è abilitato per impostazione predefinita per una migliore gestione della memoria. Per saperne di più su huge_pages, consulta la documentazione di PostgreSQL .

  • Imposta max_locks_per_transaction

    Il valore max_locks_per_transaction indica il numero di oggetti di database che possono essere bloccati contemporaneamente. Nella maggior parte dei casi, il valore predefinito di 64 è sufficiente. Tuttavia, se hai a che fare con un set di dati di grandi dimensioni, potresti riscontrare errori OOM. Valuta la possibilità di aumentare il valore di max_locks_per_transaction in modo sufficiente per evitare errori OOM.

    Il valore di max_locks_per_transaction deve essere max_locks_per_transaction * (max_connections + max_prepared_transactions) oggetti. Ciò significa che se hai 300.000 oggetti e il valore di max_connections è 200, allora 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 una singola transazione serializzabile. In questo scenario, valuta la possibilità di aumentare max_pred_locks_per_transaction a un valore ragionevolmente elevato. Come max_locks_per_transaction, anche max_pred_locks_per_transaction utilizza la memoria condivisa, quindi non impostare un valore eccessivamente elevato.

  • Se la memoria utilizzata è ancora elevata e ritieni che queste 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.

Passaggi successivi