Come posso risolvere i problemi di utilizzo elevato di CPU per Amazon RDS o Amazon Aurora PostgreSQL?

10 minuti di lettura
0

Desidero identificare e risolvere la causa dell'elevato utilizzo della CPU in Amazon Relational Database Service (Amazon RDS) o Amazon Aurora PostgreSQL Compatible Edition.

Breve descrizione

Se noti che il tuo carico ha un elevato utilizzo della CPU, utilizza una combinazione dei seguenti strumenti per identificare la causa:

Soluzione

Metriche di Amazon CloudWatch

Usa le metriche di CloudWatch per identificare i modelli di CPU per periodi prolungati. Confronta i grafici WriteIOPS, ReadIOPS, ReadThroughput, WriteThroughput con l'utilizzo della CPU per trovare i momenti in cui il carico di lavoro ha causato un aumento della CPU.

Dopo aver identificato l'intervallo di tempo, rivedi i dati di Enhanced Monitoring associati alla tua istanza database. È possibile impostare Enhanced Monitoring o per raccogliere dati a intervalli di 1, 5, 10, 15, 30 o 60 secondi. Quindi, puoi raccogliere dati a un livello più granulare rispetto a CloudWatch.

Enhanced Monitoring

Enhanced Monitoring fornisce una visualizzazione a livello di sistema operativo (OS). Questa visualizzazione può aiutare a identificare la causa di un carico elevato della CPU a livello granulare. Ad esempio, è possibile esaminare il carico medio, la distribuzione della CPU (System% o Nice%) e l'elenco dei processi del sistema operativo.

Con Enhanced Monitoring, puoi controllare i dati LoadAverageMinute a intervalli di 1, 5 e 15 minuti. Una media di carico superiore al numero di vCPU indica che l'istanza è sottoposta a un carico pesante. Se il carico medio è inferiore al numero di vCPU per la classe di istanza database, la limitazione della CPU potrebbe non causare la latenza dell'applicazione. Quando diagnostichi la causa dell'utilizzo della CPU, controlla la media del carico per evitare falsi positivi.

Ad esempio, supponiamo di avere un'istanza DB che utilizza una classe di istanza db.m5.2xlarge con 3000 Provisioned IOPS che raggiunge il limite della CPU. Nell'esempio seguente, alla classe di istanza sono associate otto vCPU. A parità di carico medio, un valore superiore a 170 indica che la macchina è sottoposta a un carico pesante durante il periodo di tempo misurato.

Minuto medio di carico

Quindici170,25
Cinque391,31
Uno596,74

Utilizzo della CPU

Utente (%)0,71
Sistema (%)4.9
Nice (%)93,92
Totale (%)99,97

Nota: in Enhanced Monitoring, Nice% rappresenta la quantità di CPU utilizzata dal carico di lavoro rispetto al database.

Dopo aver attivato Enhanced Monitoring, puoi anche controllare l'elenco dei processi del sistema operativo associato all'istanza DB. Il monitoraggio avanzato mostra un massimo di 100 processi e può aiutarti a identificare i processi con il maggiore impatto sulle prestazioni. È possibile combinare i risultati di Enhanced Monitoring con i risultati pg_stat_activity per identificare l'utilizzo delle risorse delle query.

Performance Insights

Usa Approfondimenti sulle prestazioni di Amazon RDS per identificare la query responsabile del carico del database. Controlla la scheda SQL che corrisponde a un determinato periodo di tempo.

Visualizzazione e cataloghi PostgreSQL nativi

A livello di motore di database, puoi usare pg_stat_activity e pg_stat_statements. Se il problema si verifica in tempo reale, utilizza pg_stat_activity o pg_stat_statements per raggruppare le macchine, i client e gli indirizzi IP che inviano più traffico. Utilizza questi dati per verificare gli incrementi nel tempo o gli incrementi nei server delle applicazioni. Puoi anche verificare se un server delle applicazioni ha sessioni bloccate o problemi di blocco. Per ulteriori informazioni, vedi pg_stat_activity e pg\ _stat_statements sul sito Web di PostgreSQL.

Per attivare pg_stat_statements, modifica il gruppo di parametri personalizzati esistente e imposta i seguenti valori:

  • Aggiungi pg_stat_statements a shared_preload_libraries
  • track_activity_query_size = 4096
  • pg_stat_statements.track = ALL
  • pg_stat_statements.max = 10000

Scegli Applica immediatamente, quindi riavvia l'istanza DB. Quindi, esegui un comando simile al seguente sul database che desideri monitorare:

demo=> select current_database();current_database
------------------
demo
(1 row)     

demo=> CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Nota: il comando precedente installa l'estensione nel database demo.

Dopo aver impostato pg_stat_statements, utilizza uno dei seguenti metodi per monitorare l'output.

Per elencare le query per total_time e vedere quale query trascorre più tempo nel database, esegui una delle seguenti query:

PostgreSQL versioni 12 e precedenti

SELECT total_time, query
FROM pg_stat_statements
ORDER BY total_time DESC LIMIT 10;

PostgreSQL versioni 13 e successive

SELECT total_plan_time+total_exec_time as total_time, query
FROM pg_stat_statements
ORDER BY 1 DESC LIMIT 10;

Per elencare le query con un rapporto di successo della cache del buffer inferiore, esegui una delle seguenti query:

PostgreSQL versioni 12 e precedenti

SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
FROM pg_stat_statements
ORDER BY total_time DESC LIMIT 10;

PostgreSQL versioni 13 e successive

SELECT query, calls, total_plan_time+total_exec_time as total_time, rows, 100.0 * shared_blks_hit / nullif(shared_blks_hit +shared_blks_read, 0) AS hit_percent
FROM pg_stat_statements
ORDER BY 3 DESC LIMIT 10;

Per elencare le query in base all'esecuzione per campionare le query nel tempo, esegui query riportata di seguito:

PostgreSQL versioni 12 e precedenti

SELECT query, calls, total_time/calls as avg_time_ms, rows/calls as avg_rows,temp_blks_read/calls as avg_tmp_read, temp_blks_written/calls as avg_temp_written
FROM pg_stat_statements
WHERE calls != 0
ORDER BY total_time DESC LIMIT 10;

PostgreSQL versioni 13 e successive

SELECT query,
calls,
(total_plan_time+total_exec_time as total_time)/calls as avg_time_ms,
 rows/calls as avg_rows,
temp_blks_read/calls as avg_tmp_read,
 temp_blks_written/calls as avg_temp_written
FROM pg_stat_statements
WHERE calls != 0
ORDER BY 3 DESC LIMIT 10;

Connessioni inattive nel database

Le connessioni inattive nel database potrebbero consumare risorse di elaborazione, come memoria e CPU. Quando l'istanza ha un elevato utilizzo della CPU, verifica la presenza di connessioni inattive nel database. Per ulteriori informazioni, consulta la sezione Impatto sulle prestazioni delle connessioni PostgreSQL inattive. Per verificare la presenza di connessioni inattive, utilizza Enhanced Monitoring per esaminare l'elenco dei processi del sistema operativo. Tuttavia, questo elenco mostra un massimo di 100 processi.

Per verificare la presenza di connessioni inattive, esegui le seguenti query a livello di database.

Esegui le seguenti query per visualizzare le sessioni correnti inattive e attive:

SELECT pid, datname, state, current_timestamp-least(query_start,xact_start) age, application_name, usename, queryFROM pg_stat_activity
WHERE query != '<IDLE>
'AND query NOT ILIKE '%pg_stat_activity%'
AND usename!='rdsadmin'
ORDER BY query_start desc;

SELECT application_name,pid,wait_event_type,wait_event,current_timestamp-least(query_start,xact_start) AS runtime, query AS current_query
FROM pg_stat_activity
WHERE not pid=pg_backend_pid()
AND query NOT ILIKE '%pg_stat_activity%'
AND usename!='rdsadmin';

Esegui le seguenti query per ottenere il numero di connessioni per utente e nome dell'applicazione:

postgres=> SELECT application_name,count(*) FROM pg_stat_activity GROUP BY application_name;
    application_name    | count
------------------------+-------
 psql                   |     1
 PostgreSQL JDBC Driver |     1
                        |     5
(3 rows)

postgres=> SELECT usename,count(*) FROM pg_stat_activity GROUP BY usename;
 usename  | count
----------+-------
 master   |     4
 user1    |     1
 rdsadmin |     2
(3 rows)

Dopo aver identificato le connessioni inattive, esegui una delle seguenti query per terminare le connessioni:

psql=> SELECT pg_terminate_backend(pid)
   FROM pg_stat_activity
   WHERE usename = 'example-username'
   AND pid <> pg_backend_pid()
   AND state in ('idle');

-oppure-

SELECT pg\_terminate\_backend (example-pid);

Se l'applicazione causa troppe connessioni, modificala in modo che la memoria e le risorse della CPU non vengano spese per la gestione di queste connessioni. È possibile modificare l'applicazione per limitare il numero di connessioni o utilizzare un pool di connessioni come PGBouncer. Puoi anche utilizzare Amazon RDS Proxy, un servizio gestito che ti consente di configurare il pool di connessioni.

Comando ANALYZE

Il comando ANALYZE raccoglie statistiche sul contenuto delle tabelle nel database e memorizza i risultati nel catalogo di sistema pg\ _statistic. Quindi, lo strumento di pianificazione di query utilizza queste statistiche per determinare i piani di esecuzione più efficienti per le query. Se non esegui ANALYZE frequentemente sulle tabelle del database, le query potrebbero consumare più risorse di calcolo. Le query consumano più risorse a causa delle statistiche obsolete presenti nel sistema per le relazioni a cui si accede. Questi problemi si verificano nelle seguenti condizioni:

  • Autovacuum non è in esecuzione frequentemente.
  • ANALYZE non è stato eseguito dopo l'aggiornamento della versione principale.

**Autovacuum non è in esecuzione frequentemente:**Autovacuum è un daemon che automatizza l'esecuzione dei comandi VACUUM e ANALYZE. Autovacuum verifica la presenza di tabelle gonfie nel database e recupera lo spazio per il riutilizzo. Il daemon autovacuum si assicura che le statistiche della tabella vengano aggiornate regolarmente eseguendo l'operazione ANALYZE ogni volta che la soglia impostata di tuple è morta. Quindi, lo strumento di pianificazione di query può utilizzare il piano di query più efficiente basato sulle statistiche recenti. Se l'autovacuum non è in esecuzione, lo strumento di pianificazione di query potrebbe creare piani di query non ottimali e comportare un maggiore consumo di risorse da parte delle query. Per ulteriori informazioni, consulta le seguenti risorse:

Per ottenere informazioni su quando autovacuum e autoanalyze sono stati eseguiti l'ultima volta sulle tabelle, esegui la seguente query:

SELECT relname, last\_autovacuum, last\_autoanalyze FROM pg\_stat\_user\_tables;

ANALYZE non è stato eseguito dopo l'aggiornamento della versione principale: i database PostgreSQL di solito incontrano problemi di prestazioni dopo qualsiasi aggiornamento importante della versione del motore. Un motivo comune di questi problemi è che l'operazione ANALYZE non viene eseguita dopo l'aggiornamento per aggiornare la tabella pg_statistic. Esegui l'operazione ANALYZE per ogni database nell'istanza database RD per PostgreSQL. Le statistiche dello strumento di ottimizzazione non vengono trasferite durante un aggiornamento importante della versione. Quindi, per evitare problemi di prestazioni dovuti al maggiore utilizzo delle risorse, rigenera tutte le statistiche.

Per generare statistiche per tutte le tabelle regolari del database corrente dopo un importante aggiornamento della versione, esegui il comando seguente senza parametri:

ANALYZE VERBOSE

Parametri di registrazione PostgreSQL

Attiva la registrazione delle query utilizzando Amazon RDS per PostgreSQL. Quindi, controlla i log degli errori di PostgreSQL per confermare che i parametri log_min_duration_statement e log_statement siano impostati su valori appropriati. Per ulteriori informazioni, consulta la sezione Segnalazione e registrazione degli errori sul sito Web PostgreSQL.

Ridurre l'utilizzo della CPU

Dopo aver identificato le query che causano un aumento della CPU, utilizza i seguenti metodi per ridurne ulteriormente l'utilizzo:

  • Per trovare opportunità di ottimizzazione, usa EXPLAIN e EXPLAIN ANALYZE per identificare le avvertenze. Per ulteriori informazioni, vedere EXPLAIN sul sito Web PostgreSQL.
  • Se c'è una query che viene eseguita ripetutamente, utilizza le istruzioni preparate per ridurre la pressione sulla CPU. L'esecuzione ripetuta di istruzioni preparate memorizza nella cache il piano di query. Poiché il piano è già memorizzato nella cache per ulteriori esecuzioni, il tempo necessario per la pianificazione è molto inferiore.

Informazioni correlate

Best practice per l’utilizzo di PostgreSQL

AWS UFFICIALE
AWS UFFICIALEAggiornata 3 mesi fa