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 essenziali per la regolazione di Aurora MySQL
Prima di regolare il database di Aurora MySQL, assicurati di sapere quali sono gli eventi di attesa e gli stati del thread e perché si verificano. Esaminare anche l'architettura di base della memoria e del disco di Aurora MySQL quando si utilizza il motore di archiviazione InnoDB. Per un utile diagramma architettonico, consulta ilManuale di riferimento MySQL
Argomenti
Eventi di attesa di Aurora MySQL
Un evento di attesa indica una risorsa per la quale è in attesa una sessione. Ad esempio, l'evento di attesa io/socket/sql/client_connection indica che un thread sta per gestire una nuova connessione. Le risorse tipiche che una sessione attende includono quanto segue:
-
Accesso a thread singolo a un buffer, ad esempio, quando una sessione sta tentando di modificare un buffer
-
Una riga attualmente bloccata da un'altra sessione
-
Un file di dati letto
-
Scrittura di un file log
Ad esempio, per soddisfare una query, la sessione potrebbe eseguire una scansione completa della tabella. Se i dati non sono già in memoria, la sessione attende il completamento dell'I/O del disco. Quando i buffer vengono letti in memoria, potrebbe essere necessario attendere perché altre sessioni accedono agli stessi buffer. Il database registra le attese utilizzando un evento di attesa predefinito. Questi eventi sono raggruppati in categorie.
Un evento di attesa non mostra di per sé un problema di prestazioni. Ad esempio, se i dati richiesti non sono in memoria, è necessaria la lettura dei dati dal disco. Se una sessione blocca una riga per un aggiornamento, un'altra sessione attende che la riga venga sbloccata in modo che possa aggiornarla. Un commit richiede di attendere il completamento della scrittura su un file di registro. Le attese sono parte integrante del normale funzionamento di un database.
Un gran numero di eventi di attesa in genere mostrano un problema di prestazioni. In questi casi, è possibile utilizzare i dati degli eventi di attesa per determinare dove stanno trascorrendo il tempo delle sessioni. Ad esempio, se un report che in genere viene eseguito in minuti ora viene eseguito per ore, è possibile identificare gli eventi di attesa che contribuiscono maggiormente al tempo di attesa totale. Se è possibile determinare le cause degli eventi di attesa principali, a volte è possibile apportare modifiche che migliorano le prestazioni. Ad esempio, se la sessione è in attesa su una riga bloccata da un'altra sessione, è possibile terminare la sessione di blocco.
Stati del thread di Aurora MySQL
Uno stato generale del thread è un valore State associato all'elaborazione generale delle query. Ad esempio, lo stato del thread sending data indica che un thread sta leggendo e filtrando le righe per una query per determinare il set di risultati corretto.
Puoi usare gli stati del thread per regoalre Aurora MySQL in modo simile a come usi gli eventi di attesa. Ad esempio, frequenti occorrenze di sending data di solito indicano che una query non utilizza un indice. Per ulteriori informazioni sugli stati del thread, consulta Stati generali del thread
Quando si utilizza Performance Insights, è vera una delle seguenti condizioni:
-
Performance Schema è attivato: Aurora MySQL mostra gli eventi di attesa anziché lo stato del thread.
-
Performance Schema non è attivato: Aurora MySQL mostra lo stato del thread.
Consigliamo di configurare il Performance Schema per la gestione automatica. Il Performance Schema fornisce ulteriori informazioni dettagliate e strumenti migliori per indagare sui potenziali problemi di prestazioni. Per ulteriori informazioni, consulta Panoramica dello schema delle prestazioni per Performance Insights su Aurora My SQL Amazon o My SQL.
Memoria di Aurora MySQL
In Aurora MySQL, le aree di memoria più importanti sono il pool di buffer e il buffer di registro.
Argomenti
Pool di buffer
Il pool di buffer è l'area di memoria condivisa in cui Aurora MySQL memorizza nella cache i dati di tabella e indice. Le query possono accedere ai dati utilizzati di frequente direttamente dalla memoria senza leggere dal disco.
Il pool di buffer è strutturato come un elenco di pagine collegato. Una pagina può contenere più righe. Aurora MySQL utilizza un algoritmo utilizzato meno di recente (LRU) per invecchiare le pagine fuori dal pool.
Per ulteriori informazioni, consulta Buffer Pool
Procedure di Aurora MySQL
Aurora MySQL utilizza un modello di procedure molto diverso da Aurora PostgreSQL.
Server MySQL (mysqld)
Il server MySQL è una procedura singola del sistema operativo denominato mysqld. Il server MySQL non genera procedure aggiuntive. Pertanto, un database di Aurora MySQL utilizza mysqld per eseguire la maggior parte del suo lavoro.
Quando si avvia il server MySQL, ascolta le connessioni di rete dai client MySQL. Quando un client si connette al database, mysqld apre un thread.
Thread
I thread del gestore delle connessioni associano ogni connessione client a un thread dedicato. Questo thread gestisce l'autenticazione, esegue istruzioni e restituisce i risultati al client. Il gestore delle connessioni crea nuovi thread quando necessario.
La cache dei thread è il set di thread disponibili. Quando una connessione termina, MySQL restituisce il thread alla cache del thread se la cache non è piena. La variabile del sistema thread_cache_size determina la dimensione della cache del thread.
Pool di thread
Il pool di thread è costituito da un certo numero di gruppi di thread. Ogni gruppo gestisce una serie di connessioni client. Quando un client si connette al database, il pool di thread assegna le connessioni ai gruppi di thread in modo round-robin. Il pool di thread separa connessioni e thread. Non esiste una relazione fissa tra le connessioni e i thread che eseguono istruzioni ricevute da tali connessioni.
