CPU

Questo evento si verifica quando un thread è attivo nella CPU o è in attesa della CPU.

Versioni del motore supportate

Queste informazioni relative all'evento di attesa sono supportate per Aurora PostgreSQL versione 9.6 e successive.

Context

L’unità di elaborazione centrale (CPU) è il componente di un computer che esegue le istruzioni. Ad esempio, le istruzioni della CPU eseguono operazioni aritmetiche e scambiano dati in memoria. Se una query aumenta il numero di istruzioni eseguite tramite il motore di database, il tempo impiegato per eseguire la query aumenta. Pianificazione CPU sta dando tempo alla CPU a un processo. La pianificazione viene orchestrata dal kernel del sistema operativo.

Argomenti

• Come sapere quando si verifica questa attesa
• Parametro DBLOADCPU
• Parametri di utilizzo di OS.CPU
• Probabile causa della pianificazione della CPU

Come sapere quando si verifica questa attesa

Questo evento di attesa CPU indica che un processo di backend è attivo nella CPU o è in attesa della CPU. Si verifica quando una query mostra le seguenti informazioni:

• La colonna pg_stat_activity.state ha il valore active.

• Le colonne wait_event_type e wait_event in pg_stat_activity sono entrambe null.

Per visualizzare i processi di backend in uso o in attesa sulla CPU, eseguire la seguente query.

SELECT * 
FROM   pg_stat_activity
WHERE  state = 'active'
AND    wait_event_type IS NULL
AND    wait_event IS NULL;

Parametro DBLOADCPU

Il parametro Performance Insights per la CPU è DBLoadCPU. Il valore di DBLoadCPU può differire dal valore del parametro Amazon CloudWatch CPUUtilization. Quest'ultimo parametro viene raccolto dall'HyperVisor per un'istanza di database.

Parametri di utilizzo di OS.CPU

I parametri del sistema operativo Performance Insights forniscono informazioni dettagliate sull'utilizzo della CPU. Ad esempio, è possibile visualizzare i seguenti parametri:

• os.cpuUtilization.nice.avg

• os.cpuUtilization.total.avg

• os.cpuUtilization.wait.avg

• os.cpuUtilization.idle.avg

Performance Insights segnala l'utilizzo della CPU da parte del motore di database come os.cpuUtilization.nice.avg.

Probabile causa della pianificazione della CPU

Dal punto di vista del sistema operativo, la CPU è attiva quando non è in esecuzione il thread inattivo. La CPU è attiva mentre esegue un calcolo, ma è attiva anche in attesa di I/O di memoria. Questo tipo di I/O domina un carico di lavoro tipico del database.

È probabile che i processi attendano di essere pianificati su una CPU quando vengono soddisfatte le seguenti condizioni:

• Il parametro CloudWatch CPUUtilization è vicino al 100 percento.

• Il carico medio è superiore al numero di vCPU, indicando un carico pesante. Puoi trovare il parametro loadAverageMinute nella sezione parametri del sistema operativo in Performance Insights.

Probabili cause di aumento delle attese

Quando l'evento di attesa della CPU si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti.

Argomenti

• Probabili cause di picchi improvvisi
• Probabili cause di alta frequenza a lungo termine
• Casi particolari

Probabili cause di picchi improvvisi

Le cause più probabili di picchi improvvisi sono le seguenti:

• L'applicazione ha aperto troppe connessioni simultanee al database. Questo scenario è noto come «tempesta di connessione».

• Il carico di lavoro dell'applicazione è cambiato in uno dei seguenti modi:

  • Nuove query

  • Aumento delle dimensioni del set di dati

  • Manutenzione o creazione dell'indice

  • Nuove funzioni

  • Nuovi operatori

  • Un aumento dell'esecuzione parallela di query

• I piani di esecuzione delle query sono cambiati. In alcuni casi, un cambiamento può causare un aumento dei buffer. Ad esempio, la query ora utilizza una scansione sequenziale quando in precedenza utilizzava un indice. In questo caso, le query richiedono più CPU per raggiungere lo stesso obiettivo.

Probabili cause di alta frequenza a lungo termine

Le cause più probabili di eventi che si ripetono per un lungo periodo:

• Troppi processi backend sono in esecuzione contemporaneamente sulla CPU. Questi processi possono essere lavoratori paralleli.

• Le query vengono eseguite in modo subottimale perché necessitano di un numero elevato di buffer.

Casi particolari

Se nessuna delle cause probabili risulta essere una causa effettiva, potrebbero verificarsi le seguenti situazioni:

• La CPU sta scambiando i processi in entrata e in uscita.

• Il passaggio del contesto della CPU è aumentato.

• Nel codice Aurora PostgreSQL mancano gli eventi di attesa.

Operazioni

Se l’evento di attesa CPU domina l'attività del database, non indica necessariamente un problema di prestazioni. Rispondi a questo evento solo quando le prestazioni diminuiscono.

Argomenti

• Indagare se il database sta causando l'aumento della CPU
• Determina se il numero di connessioni è aumentato
• Rispondere alle modifiche del carico di lavoro

Indagare se il database sta causando l'aumento della CPU

Esamina il parametro os.cpuUtilization.nice.avg in Performance Insights. Se questo valore è molto inferiore all'utilizzo della CPU, i processi nondatabase sono il principale contributore della CPU.

Determina se il numero di connessioni è aumentato

Esamina il parametro DatabaseConnections in Amazon CloudWatch. L'azione dipende dal fatto che il numero sia aumentato o diminuito durante il periodo di aumento degli eventi di attesa della CPU.

Le connessioni sono aumentate

Se il numero di connessioni è aumentato, confrontare il numero di processi back-end che consumano la vCPU con il numero di vCPU. Gli scenari possibili sono i seguenti:

• Il numero di processi backend che consumano vCPU è inferiore al numero di vCPU.

  In questo caso, il numero di connessioni non è un problema. Tuttavia, è comunque possibile provare a ridurre l'utilizzo della CPU.

• Il numero di processi backend che consumano vCPUs è inferiore al numero di vCPU.

  In questo caso, valuta le seguenti opzioni:

  • Riduci il numero di processi back-end collegati al database. Ad esempio, implementa una soluzione di connection pooling come RDS Proxy. Per ulteriori informazioni, consultare Utilizzo di Server proxy per Amazon RDS per Aurora.

  • Aggiorna le dimensioni dell'istanza per ottenere un numero maggiore di vCPUs.

  • Reindirizza alcuni carichi di lavoro di sola lettura ai nodi del lettore, se applicabile.

Le connessioni sono aumentate

Esamina il parametro blks_hit in Performance Insights. Cerca una correlazione tra un aumento blks_hit e utilizzo CPU. Gli scenari possibili sono i seguenti:

• Utilizzo CPU e blks_hit sono correlati.

  In questo caso, trova le istruzioni SQL principali collegate all'utilizzo della CPU e cerca le modifiche al piano. Puoi utilizzare una delle seguenti tecniche:

  • Spiegare i piani manualmente e confrontarli con il piano di esecuzione previsto.

  • Cercare un aumento degli hit di blocco al secondo e dei blocchi locali al secondo. Nella sezione Top SQL della dashboard Performance Insights, scegli Preferenze.

• Utilizzo CPU e blks_hit non sono correlati.

  In questo caso, determinare se si verifica una delle seguenti condizioni:

  • L'applicazione si sta rapidamente connettendo e disconnettendo dal database.

    Diagnosticare questo comportamento attivando log_connections e log_disconnections, quindi analizzando i registri PostgreSQL. Considerare l'utilizzo dell’analizzatore di log pgbadger. Per ulteriori informazioni, consultare https://github.com/darold/pgbadger.

  • Il sistema operativo è sovraccarico.

    In questo caso, Performance Insights mostra che i processi back-end consumano la CPU per un tempo più lungo del solito. Cerca prove nei parametri os.cpuUtilization di Performance Insights o nel parametro CloudWatch CPUUtilization. Se il sistema operativo è sovraccarico, esamina i parametri di Enhanced Monitoring per effettuare ulteriori diagnosi. In particolare, guarda l'elenco dei processi e la percentuale di CPU consumata da ciascun processo.

  • Le istruzioni SQL principali consumano troppa CPU.

    Esaminare le istruzioni collegate all'utilizzo della CPU per verificare se possono utilizzare meno CPU. Esegui il comando EXPLAIN e concentrati sui nodi del piano che hanno il maggior impatto. Prendi in considerazione l'utilizzo di un visualizzatore del piano di esecuzione PostgreSQL. Per provare questo strumento, vedi http://explain.dalibo.com/.

Rispondere alle modifiche del carico di lavoro

Se il carico di lavoro è cambiato, cerca i seguenti tipi di modifiche:

Nuove query

Verifica se sono previste le nuove query. In tal caso, assicurarsi che siano previsti i piani di esecuzione e il numero di esecuzioni al secondo.

Aumento delle dimensioni del set di dati

Determina se il partizionamento, se non è già implementato, potrebbe essere d'aiuto. Questa strategia potrebbe ridurre il numero di pagine che una query deve recuperare.

Manutenzione o creazione dell'indice

Verificare se è previsto il programma per la manutenzione. Una best practice è pianificare le attività di manutenzione al di fuori delle attività di picco.

Nuove funzioni

Verifica se queste funzioni funzionano come previsto durante il test. In particolare, controlla se è previsto il numero di esecuzioni al secondo.

Nuovi operatori

Verifica se queste funzioni funzionano come previsto durante il test.

Un aumento dell'esecuzione di query parallele

Determina se si è verificata una delle seguenti situazioni:

• Le relazioni o gli indici coinvolti sono improvvisamente cresciuti di dimensioni in modo che differiscano in modo significativo da min_parallel_table_scan_size o min_parallel_index_scan_size.

• Cambiamenti recenti sono stati apportati a parallel_setup_cost o parallel_tuple_cost.

• Cambiamenti recenti sono stati apportati a max_parallel_workers o max_parallel_workers_per_gather.