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 Amazon RDS , 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 informazioni su tutti gli eventi MariadB e SQL My wait, vedi Tabelle di riepilogo degli eventi Wait
nella documentazione personale. SQL -
Per informazioni su tutti gli eventi di SQL attesa di Postgre, consulta The Statistics Collector > Wait Event
tables nella documentazione di Postgre. SQL -
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 del server, consulta Types of Waits nella documentazione del
server. SQL
Nota
Per Oracle, i processi in background a volte funzionano senza un'SQListruzione associata. 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.
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.
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 integrato che determina il piano più efficiente per una query. SQL
Per le istanze DB, Performance Insights raccoglie automaticamente i piani di esecuzione. Per diagnosticare i problemi di SQL prestazioni, esamina i piani acquisiti per le query ad alto numero di risorse. SQL I piani mostrano come il database ha analizzato ed eseguito le interrogazioni.
Per informazioni su come analizzare il carico del DB utilizzando i piani, consulta:
Acquisizione del piano
Ogni cinque minuti, Performance Insights identifica le query che richiedono più risorse e ne registra i piani. Pertanto, non devi raccogliere e gestire manualmente un gran numero di piani. Puoi invece utilizzare la SQL scheda Top 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 Accedere a più SQL testo nella dashboard 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
Per impostazione predefinita, la SQL scheda Top mostra le interrogazioni riassuntive. 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.
Quando si seleziona una query di riepilogo, la console mostra tutti i piani per le istruzioni secondarie 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.
