Avviso di fine del supporto: il 30 settembre 2027, AWS terminerà il supporto per Amazon DevOps Guru. Dopo il 30 settembre 2027, non potrai più accedere alla console Amazon Guru o alle risorse Amazon DevOps Guru. DevOps Per ulteriori informazioni, consulta Fine del supporto di Amazon DevOps Guru.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Concetti chiave per l'ottimizzazione delle prestazioni del database

DevOpsGuru for RDS presuppone che tu conosca alcuni concetti chiave relativi alle prestazioni. Per ulteriori informazioni su questi concetti, consulta Overview of Performance Insights nella Amazon Aurora User Guide o Overview of Performance Insights nella Amazon RDS User Guide.

Metriche

Un parametro rappresenta un set di punti dati in ordine cronologico. Pensa a un parametro come a una variabile da monitorare e ai punti di dati come i valori di questa variabile nel tempo. Amazon RDS fornisce metriche in tempo reale per il database e per il sistema operativo (OS) su cui viene eseguita l'istanza DB. Puoi visualizzare tutte le metriche di sistema e le informazioni di processo per le tue istanze DB Amazon RDS sulla console Amazon RDS. DevOps Guru for RDS monitora e fornisce approfondimenti per alcune di queste metriche. Per ulteriori informazioni, consulta Metriche di monitoraggio in un cluster Amazon Aurora o Metriche di monitoraggio in un'istanza di Amazon Relational Database Service.

Rilevamento dei problemi

DevOpsGuru for RDS utilizza le metriche del database e del sistema operativo (OS) per rilevare i problemi critici relativi alle prestazioni del database, siano essi imminenti o in corso. Esistono 2 modi principali in cui funziona il rilevamento dei problemi di DevOps Guru for RDS:

Rilevamento di problemi con le soglie

Le soglie sono i valori limite rispetto ai quali vengono valutate le metriche monitorate. Puoi pensare a una soglia come a una linea orizzontale su un grafico delle metriche che separa il comportamento normale da quello potenzialmente problematico. DevOps Guru for RDS monitora metriche specifiche e crea soglie analizzando quali livelli sono considerati potenzialmente problematici per una risorsa specifica. DevOpsGuru for RDS crea quindi informazioni dettagliate nella console DevOps Guru quando i nuovi valori delle metriche superano una soglia specificata in un determinato periodo di tempo in modo coerente. Gli approfondimenti contengono raccomandazioni per prevenire impatti futuri sulle prestazioni del database.

Ad esempio, DevOps Guru for RDS potrebbe monitorare il numero di tabelle temporanee che utilizzano il disco per un periodo di 15 minuti e creare una panoramica quando la frequenza di tabelle temporanee che utilizzano il disco al secondo è anormalmente elevata. L'aumento dei livelli di utilizzo delle tabelle temporanee su disco potrebbe influire sulle prestazioni del database. Esponendo questa situazione prima che diventi critica, DevOps Guru for RDS ti aiuta a intraprendere azioni correttive per prevenire i problemi.

Rilevamento di problemi legati alle anomalie

Sebbene le soglie forniscano un modo semplice ed efficace per rilevare i problemi del database, in alcune situazioni non sono sufficienti. Si consideri un caso in cui i valori delle metriche aumentano e assumono regolarmente comportamenti potenzialmente problematici a causa di un processo noto, ad esempio un processo di reporting giornaliero. Poiché tali picchi sono prevedibili, la creazione di informazioni e notifiche per ciascuno di essi sarebbe controproducente e comporterebbe probabilmente un aumento dell'attenzione.

Tuttavia, è ancora necessario rilevare picchi molto insoliti, poiché metriche molto più elevate rispetto alle altre o che durano molto più a lungo potrebbero rappresentare reali problemi di prestazioni del database. Per risolvere questo problema, DevOps Guru for RDS monitora determinate metriche per rilevare quando il comportamento di una metrica diventa molto insolito o anomalo. DevOpsGuru riporta quindi queste anomalie negli approfondimenti.

Ad esempio, DevOps Guru for RDS potrebbe creare un'idea quando il carico del database non solo è elevato, ma si discosta anche in modo significativo dal suo comportamento abituale, il che indica un grave rallentamento imprevisto delle operazioni del database. Riconoscendo solo i picchi anomali di carico del DB, DevOps Guru for RDS consente di concentrarsi sui problemi veramente importanti.

carico DB

Il concetto chiave per l'ottimizzazione del database è la metrica del carico del database (carico DB). Il carico del DB rappresenta il livello di occupazione del database in un determinato momento. Un aumento del carico del DB significa un aumento dell'attività del database.

Una sessione database rappresenta il dialogo di un'applicazione con un database relazionale. Una sessione attiva è una sessione in corso di esecuzione di una richiesta di database. Una sessione è attiva quando è in esecuzione sulla CPU o in attesa che una risorsa diventi disponibile in modo che possa proseguire. Ad esempio, una sessione attiva potrebbe attendere la lettura di una pagina in memoria e quindi consumare la CPU mentre legge i dati dalla pagina.

La DBLoad metrica in Performance Insights viene misurata in sessioni attive medie (AAS). Per calcolare l'AAS, Performance Insights campiona il numero di sessioni attive ogni secondo. Per un periodo di tempo specifico, l'AAS è il numero totale di sessioni attive diviso per il numero totale di campioni. Un valore AAS pari a 2 significa che, in media, nelle richieste erano attive 2 sessioni in un dato momento.

Un'analogia per il carico DB è l'attività in un magazzino. Supponiamo che il magazzino impieghi 100 lavoratori. Se arriva 1 ordine, 1 lavoratore evade l'ordine mentre gli altri lavoratori sono inattivi. Se arrivano 100 o più ordini, tutti i 100 lavoratori evadono gli ordini contemporaneamente. Se si periodicamente si esegue un campionamento di quanti lavoratori sono attivi in un determinato periodo di tempo, è possibile calcolare il numero medio di lavoratori attivi. Il calcolo dimostra che, in media,N lavoratori sono impegnati a gestire gli ordini in un dato momento. Se la media era di 50 lavoratori ieri e 75 lavoratori oggi, il livello di attività nel magazzino è aumentato. Allo stesso modo, il carico DB aumenta con l'aumentare dell'attività di sessione.

Per ulteriori informazioni, consulta Database load nella Amazon Aurora User Guide o Database load nella Amazon RDS User Guide.

Eventi di attesa

Un evento di attesa è un tipo di strumentazione del database che indica quale risorsa è attesa da una sessione di database per poter procedere. Quando Performance Insights conta le sessioni attive per calcolare il carico del database, registra anche gli eventi di attesa che causano l'attesa delle sessioni attive. Questa tecnica consente a Performance Insights di mostrare quali eventi di attesa stanno contribuendo al carico del DB.

Ogni sessione attiva è in esecuzione sulla CPU o in attesa. Ad esempio, le sessioni consumano CPU quando effettuano ricerche nella memoria, eseguono un calcolo o eseguono codice procedurale. Quando le sessioni non consumano CPU, potrebbero essere in attesa della lettura di un file di dati o della scrittura di un registro. Maggiore è il tempo in cui una sessione attende le risorse, minore è il tempo in cui viene eseguita sulla CPU.

Quando si ottimizza un database, spesso si cerca di trovare le risorse attese dalle sessioni. Ad esempio, due o tre eventi di attesa potrebbero rappresentare il 90% del carico del DB. Questa misura significa che, in media, le sessioni attive trascorrono la maggior parte del tempo in attesa di un numero limitato di risorse. Se riesci a scoprire la causa di queste attese, puoi provare a risolvere il problema.

Considera l'analogia di un addetto al magazzino. Viene fornito un ordine per un libro. Il lavoratore potrebbe subire un ritardo nell'evasione dell'ordine. Ad esempio, un altro lavoratore potrebbe attualmente rifornire gli scaffali o un carrello potrebbe non essere disponibile. Oppure il sistema utilizzato per inserire lo stato dell'ordine potrebbe essere lento. Maggiore è il tempo di attesa del lavoratore, maggiore è il tempo impiegato per l'evasione dell'ordine. L'attesa è una parte naturale del flusso di lavoro del magazzino, ma se i tempi di attesa diventano eccessivi, la produttività diminuisce. Allo stesso modo, attese di sessione ripetute o lunghe possono compromettere le prestazioni del database.

Per ulteriori informazioni sugli eventi di attesa in Amazon Aurora, consulta Tuning with wait events for Aurora PostgreSQL e Tuning with wait events for Aurora MySQL nella Amazon Aurora User Guide.

Per ulteriori informazioni sugli eventi di attesa in altri database Amazon RDS, consulta Tuning with wait events for RDS for PostgreSQL nella Amazon RDS User Guide.