Risolvere i problemi di utilizzo elevato della CPU in Database di Azure per PostgreSQL - Server flessibile
SI APPLICA A:
Database di Azure per PostgreSQL - Server flessibile
Questo articolo illustra come identificare rapidamente la causa radice dell'utilizzo elevato della CPU e le possibili azioni correttive per controllare l'utilizzo della CPU quando si usa Database di Azure per PostgreSQL server flessibile.
In questo articolo si apprenderà:
- Informazioni sulle guide alla risoluzione dei problemi per identificare e ottenere raccomandazioni per attenuare le cause radice.
- Informazioni sugli strumenti per identificare un utilizzo elevato della CPU, ad esempio metriche di Azure, Query Store e pg_stat_statements.
- Come identificare le cause radice, ad esempio query a esecuzione prolungata e connessioni totali.
- Come risolvere l'utilizzo elevato della CPU usando le tabelle Explain Analyze, Connessione ion Pooling e Vacuuming.
Guide alla risoluzione dei problemi
È possibile trovare le guide alla risoluzione dei problemi di funzionalità disponibili nel portale del server flessibile Database di Azure per PostgreSQL la probabile causa radice e le raccomandazioni per ridurre lo scenario elevato della CPU. Come configurare le guide alla risoluzione dei problemi per usarle, seguire le guide alla risoluzione dei problemi di installazione.
Strumenti per identificare l'utilizzo elevato della CPU
Prendere in considerazione questi strumenti per identificare un utilizzo elevato della CPU.
Metriche di Azure
Metriche di Azure è un buon punto di partenza per controllare l'utilizzo della CPU per la data e il periodo definito. Le metriche forniscono informazioni sulla durata del tempo durante la quale l'utilizzo della CPU è elevato. Confrontare i grafici di operazioni di I/O di scrittura, operazioni di I/O lettura, velocità effettiva di lettura e velocità effettiva di scrittura con utilizzo della CPU per individuare i tempi in cui il carico di lavoro ha causato un utilizzo elevato della CPU. Per il monitoraggio proattivo, è possibile configurare gli avvisi sulle metriche. Per indicazioni dettagliate, vedere Metriche di Azure.
Archivio query
Query Store acquisisce automaticamente la cronologia delle query e delle statistiche di runtime e le mantiene per la revisione. Seziona i dati in base al tempo in modo che sia possibile visualizzare i modelli di utilizzo temporali. I dati per tutti gli utenti, i database e le query vengono archiviati in un database denominato azure_sys nell'istanza del server flessibile Database di Azure per PostgreSQL. Per istruzioni dettagliate, vedere Query Store.
pg_stat_statements
L'estensione pg_stat_statements consente di identificare le query che consumano tempo nel server.
Tempo medio o medio di esecuzione
Per Postgres versioni 13 e successive, usare l'istruzione seguente per visualizzare le prime cinque istruzioni SQL per media o media durata di esecuzione:
SELECT userid::regrole, dbid, query, mean_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time
DESC LIMIT 5;
Tempo totale di esecuzione
Eseguire le istruzioni seguenti per visualizzare le prime cinque istruzioni SQL in base al tempo di esecuzione totale.
Per Postgres versioni 13 e successive, usare l'istruzione seguente per visualizzare le prime cinque istruzioni SQL in base al tempo di esecuzione totale:
SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY total_exec_time
DESC LIMIT 5;
Identificare le cause radice
Se i livelli di consumo della CPU sono elevati in generale, le possibili cause principali potrebbero essere le seguenti:
Transazioni con esecuzione prolungata
Le transazioni con esecuzione prolungata possono utilizzare risorse CPU che possono causare un utilizzo elevato della CPU.
La query seguente consente di identificare le connessioni in esecuzione per il tempo più lungo:
SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;
Numero totale di connessioni e connessioni numeri per stato
Un numero elevato di connessioni al database è anche un altro problema che potrebbe causare un aumento dell'utilizzo della CPU e della memoria.
La query seguente fornisce informazioni sul numero di connessioni in base allo stato:
SELECT state, count(*)
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
GROUP BY 1 ORDER BY 1;
Risolvere l'utilizzo elevato della CPU
Usare Explain Analyze, PG Bouncer, connection pooling e terminate transazioni a esecuzione prolungata per risolvere un utilizzo elevato della CPU.
Usare Explain Analyze
Dopo aver appreso la query in esecuzione per molto tempo, usare EXPLAIN per analizzare ulteriormente la query e ottimizzarla.
Per altre informazioni sul comando EXPLAIN , vedere Spiega piano.
PGBouncer e pool di connessioni
In situazioni in cui sono presenti numerose connessioni inattive o molte connessioni, che utilizzano la CPU considerano l'uso di un pool di connessioni come PgBouncer.
Per altri dettagli su PgBouncer, vedere:
Database di Azure per PostgreSQL server flessibile offre PgBouncer come soluzione di pool di connessioni predefinita. Per altre informazioni, vedere PgBouncer
Terminare le transazioni a esecuzione prolungata
È possibile prendere in considerazione l'eliminazione di una transazione a esecuzione prolungata come opzione.
Per terminare il PID di una sessione, è necessario rilevare il PID usando la query seguente:
SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;
È anche possibile filtrare in base ad altre proprietà, ad usename esempio (nome utente), datname (nome database) e così via.
Dopo aver ottenuto il PID della sessione, è possibile terminare usando la query seguente:
SELECT pg_terminate_backend(pid);
Monitorare le statistiche di vuoto e tabella
Mantenere aggiornate le statistiche delle tabelle consente di migliorare le prestazioni delle query. Monitorare se viene eseguita la normale autovacuumazione.
La query seguente consente di identificare le tabelle che richiedono il vuoto:
select schemaname,relname,n_dead_tup,n_live_tup,last_vacuum,last_analyze,last_autovacuum,last_autoanalyze
from pg_stat_all_tables where n_live_tup > 0;
last_autovacuum le colonne e last_autoanalyze forniscono la data e l'ora dell'ultima analisi automatica della tabella. Se le tabelle non vengono sottoposte a vuoto regolarmente, seguire questa procedura per ottimizzare l'autovacuum. Per altre informazioni sulla risoluzione dei problemi e sull'ottimizzazione di autovacuum, vedere Risoluzione dei problemi di Autovacuum.
Una soluzione a breve termine consiste nell'eseguire un'analisi manuale a vuoto delle tabelle in cui vengono visualizzate query lente:
vacuum analyze <table_name>;