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à.
Caricamento database
Il carico del database (carico DB) misura il livello di attività della sessione nel database. DBLoad
è la metrica chiave di Performance Insights e Performance Insights raccoglie il carico del DB ogni secondo.
Sessioni attive
Una sessione database rappresenta il dialogo di un'applicazione con un database relazionale. Una sessione attiva è una connessione che ha inviato lavoro a un motore del database ed è in attesa di una risposta dal motore del database.
Una sessione è attiva quando è in esecuzione CPU o in attesa che una risorsa diventi disponibile per poter procedere. Ad esempio, una sessione attiva potrebbe attendere che una pagina (o un blocco) venga letta in memoria e quindi CPU consumarla mentre legge i dati dalla pagina.
Media delle sessioni attive
La media delle sessioni attive (AAS) è l'unità per la DBLoad
metrica in Performance Insights. Misura quante sessioni sono attive contemporaneamente nel database.
Ogni secondo, Performance Insights esegue il campionamento del numero di sessioni che eseguono contemporaneamente una query. Per ogni sessione attiva, Performance Insights raccoglie i seguenti dati:
-
SQLdichiarazione
-
stato della sessione (in esecuzione CPU o in attesa)
-
Host
-
Utente che esegue il SQL
Performance Insights calcola AAS dividendo il numero totale di sessioni per il numero di campioni per un periodo di tempo specifico. Ad esempio, nella tabella seguente vengono riportati 5 campioni consecutivi di una query in esecuzione, dove ogni campione viene acquisito a intervalli di 1 secondo.
Project N.E.M.O. | Numero di sessioni che eseguono query | AAS | Calcolo |
---|---|---|---|
1 | 2 | 2 | 2 sessioni totali / 1 campione |
2 | 0 | 1 | 2 sessioni totali / 2 campioni |
3 | 4 | 2 | 6 sessioni totali / 3 campioni |
4 | 0 | 1.5 | 6 sessioni totali / 4 campioni |
5 | 4 | 2 | 10 sessioni totali / 5 campioni |
Nell'esempio precedente, il carico del DB per l'intervallo di tempo era 2. AAS Questa misurazione significa che, in media, sono state attive 2 sessioni alla volta durante il periodo in cui sono stati acquisiti i 5 campioni.
Media delle esecuzioni attive
La media delle esecuzioni attive (AAE) al secondo è correlata a. AAS Per calcolareAAE, Performance Insights divide il tempo totale di esecuzione di una query per l'intervallo di tempo. La tabella seguente mostra il AAE calcolo per la stessa query nella tabella precedente.
Tempo trascorso (sec) | Tempo di esecuzione totale (sec) | AAE | Calcolo |
---|---|---|---|
60 | 120 | 2 | 120 secondi di esecuzione/60 secondi trascorsi |
120 | 120 | 1 | 120 secondi di esecuzione/120 secondi trascorsi |
180 | 380 | 2.11 | 380 secondi di esecuzione/180 secondi trascorsi |
240 | 380 | 1.58 | 380 secondi di esecuzione/240 secondi trascorsi |
300 | 600 | 2 | 600 secondi di esecuzione/300 secondi trascorsi |
Nella maggior parte dei casi, gli AAS e AAE per una query sono all'incirca uguali. Tuttavia, poiché gli input per i calcoli sono origini dati diverse, i calcoli spesso variano leggermente.
Dimensioni
Il parametro db.load
è diverso dagli altri parametri di serie temporali in quanto può essere suddiviso in sottocomponenti detti dimensioni. Le dimensioni possono essere considerate come categorie "slice by" (dividi per) per le diverse caratteristiche del parametro DBLoad
.
Quando si diagnosticano problemi di prestazioni, le dimensioni seguenti sono spesso le più utili:
Argomenti
Per un elenco completo delle dimensioni dei motori Aurora, consulta. Carico del database suddiviso per dimensioni
Eventi di attesa
Un evento di attesa fa sì che un'SQListruzione attenda il verificarsi di un evento specifico prima di poter continuare a funzionare. Gli eventi di attesa sono una dimensione o una categoria importante per il caricamento del database perché indicano dove il lavoro è impedito.
Ogni sessione attiva è in esecuzione CPU o in attesa. Ad esempio, le sessioni consumano CPU quando cercano un buffer nella memoria, eseguono un calcolo o eseguono codice procedurale. Quando le sessioni non si consumanoCPU, potrebbero attendere che un buffer di memoria si liberi, che venga letto un file di dati o che venga scritto un registro. Più tempo impiega una sessione per attendere le risorse, minore è il tempo di esecuzione su. CPU
Quando si sintonizza un database, si tenta spesso di scoprire le risorse che le sessioni sono in attesa. Ad esempio, due o tre eventi di attesa potrebbero rappresentare il 90% del carico 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 fornire una soluzione.
Gli eventi di attesa variano in base al motore database:
-
Per un elenco degli eventi di attesa comuni per Aurora MySQL, vedi. Eventi Aurora My wait SQL Per informazioni su come sintonizzarsi utilizzando questi eventi di attesa, consulta Ottimizzazione di Aurora MySQL.
-
Per informazioni su tutti gli eventi e SQL My wait, vedi Tabelle di riepilogo degli eventi Wait
nella documentazione personale. SQL -
Per un elenco degli eventi di attesa comuni per Aurora SQL Postgre, vedi. Eventi di attesa Amazon Aurora PostgreSQL Per informazioni su come sintonizzarsi utilizzando questi eventi di attesa, consulta Sintonizzazione degli eventi di attesa per Aurora PostgreSQL.
-
Per informazioni su tutti gli eventi di SQL attesa di Postgre, consulta The Statistics Collector > Wait Event
tables nella documentazione di Postgre. SQL
In alto SQL
Laddove gli eventi di attesa mostrano problemi, la parte superiore SQL mostra quali sono le query che contribuiscono maggiormente al carico del DB. Ad esempio, molte query potrebbero essere attualmente in esecuzione nel database, ma una singola query potrebbe consumare il 99 percento del carico DB. In questo caso, il carico elevato potrebbe indicare un problema con la query.
Per impostazione predefinita, la console Performance Insights visualizza le principali SQL query che contribuiscono al carico del database. La console mostra anche le statistiche pertinenti per ogni istruzione. Per diagnosticare problemi di prestazioni per un'istruzione specifica, è possibile esaminarne il piano di esecuzione.