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
L'opzione Caricamento del database misura il livello di attività della sessione nel database. Il parametro chiave in Performance Insights è DBLoad, che viene raccolto 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 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 (o blocco) in memoria e quindi consumare la CPU mentre legge i dati dalla pagina.
Media delle sessioni attive
La media delle sessioni attive (AAS) è l'unità per il parametro DBLoad 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:
-
Istruzione SQL
-
Stato della sessione (in esecuzione sulla CPU o in attesa)
-
Host
-
Utente che esegue SQL
Performance Insights calcola il valore delle sessioni attive medie (AAS) dividendo il numero totale di sessioni per il numero totale 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 DB per l'intervallo di tempo è 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.
Un'analogia per il carico del database è l'attività in un magazzino. Supponiamo che il magazzino impieghi 100 lavoratori. Se arriva 1 ordine, 1 lavoratore evade l'ordine mentre 99 lavoratori sono inattivi. Se arrivano 100 ordini, tutti i 100 lavoratori gestiscono gli ordini contemporaneamente. Se ogni 15 minuti un manager annota il numero di lavoratori attivi contemporaneamente, somma questi numeri alla fine della giornata e quindi divide il totale per il numero di campioni, il manager calcola il numero medio di lavoratori attivi in un dato momento. Se la media è pari a 50 lavoratori ieri e 75 lavoratori oggi, il livello medio di attività nel magazzino è aumentato. Allo stesso modo, il carico del database aumenta con l'aumentare dell'attività della sessione del database.
Media delle esecuzioni attive
La media delle esecuzioni attive (AAE) al secondo è correlata all'AAS. Per calcolare l'AAE, Performance Insights divide il tempo totale di esecuzione di una query per l'intervallo di tempo. Nella tabella seguente viene illustrato il calcolo AAE 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, l'AAS e AAE per una query sono quasi 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:
Per un elenco completo delle dimensioni per i motori Amazon RDS, consulta Carico del database suddiviso per dimensioni.
Eventi di attesa
Un evento di attesa fa sì che un'istruzione SQL attenda che si verifichi un evento specifico prima che possa continuare l'esecuzione. 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 sulla CPU o in attesa. Ad esempio, le sessioni consumano la CPU quando cercano in memoria un buffer, eseguono un calcolo o eseguono codice procedurale. Quando le sessioni non consumano la CPU, potrebbero essere in attesa che un buffer di memoria diventi libero, un file di dati da leggere o un registro in cui scrivere. Maggiore è il tempo in cui una sessione attende le risorse, minore è il tempo in cui viene eseguita sulla 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.
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 lavoratore diverso potrebbe attualmente rifornire gli scaffali, un carrello potrebbe non essere disponibile. Oppure il sistema utilizzato per inserire lo stato dell'ordine potrebbe essere lento. Più a lungo il lavoratore attende, più tempo ci vuole per evadere l'ordine. L'attesa è una parte naturale del flusso di lavoro del magazzino, ma se il tempo di attesa diventa eccessivo, la produttività diminuisce. Allo stesso modo, attese di sessione ripetute o lunghe possono compromettere le prestazioni del database. Per ulteriori informazioni, consulta Tuning with wait events for Aurora PostgreSQL (Sintonizzazione degli eventi di attesa per Aurora PostgreSQL) e Tuning with wait events for Aurora MySQL (Sintonizzazione con eventi di attesa per Aurora MySQL) in Guida per l'utente di Amazon Aurora.
Gli eventi di attesa variano in base al motore database:
-
Per informazioni su tutti gli eventi di attesa MariaDB e MySQL, consulta Wait Event Summary Tables
nella documentazione di MySQL. -
Per informazioni su tutti gli eventi di attesa PostgreSQL, consulta la pagina relativa al processo di raccolta delle statistiche e alle tabelle degli eventi di attesa
nella documentazione di PostgreSQL. -
Per informazioni su tutti gli eventi di attesa Oracle, consulta l'argomento con le descrizioni degli eventi di attesa
nella documentazione Oracle. -
Per informazioni su tutti gli eventi di attesa SQL Server, consulta Types of Waits
nella documentazione SQL Server.
Nota
Per Oracle, i processi in background a volte funzionano senza istruzioni SQL associate. In questi casi, Performance Insights segnala il tipo di processo in background concatenato da due punti e la classe di attesa associata al processo in background. I tipi di processo in background includono LGWR, ARC0, PMON, e così via.
Ad esempio, quando lo strumento di archiviazione esegue I/O, il report di Performance Insights è simile a ARC1:System I/O. A volte manca anche il tipo di processo in background e Performance Insights indica solo la classe di attesa, ad esempio :System
I/O.
Prime istruzioni SQL
Mentre gli eventi di attesa mostrano i colli di bottiglia, il primo SQL mostra quali query stanno contribuendo maggiormente al caricamento 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 di Performance Insights visualizza le prime query SQL che contribuiscono al caricamento 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.
Piani
Un piano di esecuzione, chiamato anche semplicemente piano, è una sequenza di passaggi che accedono ai dati. Ad esempio, un piano per unire le tabelle t1 e t2 potrebbe scorrere in loop tutte le righe in t1 e confrontare ogni riga con una riga in t2. In un database relazionale, un ottimizzatore è un codice incorporato che determina il piano più efficiente per una query SQL.
Per le istanze database Oracle, Performance Insights raccoglie automaticamente i piani di esecuzione. Per diagnosticare i problemi di prestazioni SQL, esamina i piani acquisiti per le query Oracle SQL ad alte risorse. I piani mostrano come Oracle Database ha analizzato ed eseguito le query.
Per informazioni su come analizzare il carico DB utilizzando i piani, consulta Analisi dei piani di esecuzione di Oracle tramite il pannello di controllo di Performance Insights.
Acquisizione del piano
Ogni cinque minuti, Performance Insights identifica le query Oracle che richiedono più risorse e acquisisce i piani. Pertanto, non devi raccogliere e gestire manualmente un gran numero di piani. Invece, puoi utilizzare la scheda Top SQL (Prime istruzioni SQL) per concentrarti sui piani per le query più problematiche.
Nota
Performance Insights non acquisisce piani per le query il cui testo supera il limite massimo di testo della query raccolte. Per ulteriori informazioni, consulta Accesso a una maggiore quantità di testo SQL nel pannello di controllo di Performance Insights.
Il periodo di conservazione per i piani di esecuzione è lo stesso dei dati di Performance Insights. L'impostazione del periodo di conservazione nel livello gratuito è Default (7 days) (Impostazione predefinita [7 giorni]). Per mantenere i dati sulle prestazioni più a lungo, specifica da 1 a 24 mesi. Per altre informazioni sui periodi di conservazione, consulta Prezzi e conservazione dei dati per Performance Insights.
Query digest
La scheda Top SQL (Prime istruzioni SQL) mostra le query digest per impostazione predefinita. Una query digest di per sé non ha un piano, ma tutte le query che utilizzano valori letterali hanno piani. Ad esempio, una query digest potrebbe includere il testo WHERE `email`=?. Il digest potrebbe contenere due query, una con il testo WHERE email=user1@example.com e un'altra con WHERE
email=user2@example.com. Ognuna di queste query letterali può includere più piani.
Se si seleziona una query digest, la console mostra tutti i piani per le istruzioni figlio del digest selezionato. Pertanto, non devi esaminare tutte le istruzioni figlio per trovare il piano. Potresti vedere piani che non sono inclusi nell'elenco delle prime 10 istruzioni figlio. La console mostra i piani per tutte le query figlio per le quali sono stati raccolti i piani, indipendentemente dal fatto che le query siano tra le prime 10.
