Concetti chiave per l'ottimizzazione delle prestazioni del database - 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 abbia familiarità con 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 parametri 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 database Amazon RDS sulla console Amazon RDS. DevOpsGuru for RDS monitora e fornisce approfondimenti per alcune di queste metriche. Per ulteriori informazioni, consulta i parametri di monitoraggio in un cluster Amazon Aurora o i parametri 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 continui. Esistono due modi principali in cui funziona il rilevamento dei problemi di DevOps Guru for RDS:

  • Utilizzo delle soglie

  • Utilizzo di anomalie

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 metrico che separa il comportamento normale da quello potenzialmente problematico. DevOpsGuru for RDS monitora metriche specifiche e crea soglie analizzando quali livelli sono considerati potenzialmente problematici per una risorsa specifica. DevOpsGuru for RDS crea quindi approfondimenti 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 consigli per prevenire futuri impatti 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 informazioni quando la frequenza delle 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 con anomalie

Sebbene le soglie offrano un modo semplice ed efficace per rilevare i problemi del database, in alcune situazioni non sono sufficienti. Prendiamo in considerazione il caso in cui i valori delle metriche aumentino e si trasformino regolarmente in comportamenti potenzialmente problematici a causa di un processo noto, ad esempio un processo quotidiano di creazione di report. Poiché tali picchi sono prevedibili, la creazione di informazioni e notifiche per ciascuno di essi sarebbe controproducente e probabilmente causerebbe un affaticamento degli avvisi.

Tuttavia, è comunque necessario rilevare picchi molto insoliti, poiché metriche molto più elevate rispetto alle altre o che durano molto più a lungo potrebbero rappresentare problemi reali 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 informazioni quando il carico del DB 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 caricamento del database (carico DB). Il carico del DB rappresenta il livello di occupazione del database in un dato 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 che sta eseguendo una richiesta al 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 indica che, in media, erano attive 2 sessioni nelle richieste 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 eseguono 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 Caricamento del database nella Guida per l'utente di Amazon Aurora o Caricamento del database nella Guida per l'utente di Amazon RDS.

Eventi di attesa

Un evento di attesa è un tipo di strumentazione del database che indica quale risorsa è in attesa una sessione di database in modo che possa 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 contribuiscono 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 calcoli 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, si cerca spesso di trovare le risorse che le sessioni attendono. 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. Più a lungo il lavoratore aspetta, più tempo impiega 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.