Risoluzione dei problemi di carico di lavoro per i database Aurora MySQL - Amazon Aurora
Parametri dell’host dell’istanzaParametri del database

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à.

Risoluzione dei problemi di carico di lavoro per i database Aurora MySQL

Il carico di lavoro del database può essere visualizzato come lettura e scrittura. Una volta compreso il “normale” carico di lavoro del database, è possibile ottimizzare le query e il server di database per soddisfare la domanda man mano che questa cambia. Esistono diversi motivi per cui le prestazioni possono cambiare, quindi il primo passo è capire cosa è cambiato.

  • È stato effettuato un aggiornamento della versione principale o secondario?

    Un aggiornamento della versione principale include modifiche al codice del motore, in particolare nell’ottimizzatore, che possono modificare il piano di esecuzione delle query. Quando si aggiornano le versioni del database, in particolare le versioni principali, è molto importante analizzare il carico di lavoro del database e ottimizzarlo di conseguenza. L’ottimizzazione può comportare l’ottimizzazione e la riscrittura delle query o l’aggiunta e l’aggiornamento delle impostazioni dei parametri, a seconda dei risultati dei test. Capire cosa sta causando l’impatto ti consentirà di iniziare a concentrarti su quell’area specifica.

    Per ulteriori informazioni, consulta Novità di MySQL 8.0 e Server and status variables and options added, deprecated, or removed in MySQL 8.0 nella documentazione di MySQL e Confronto tra Aurora MySQL versione 2 e Aurora MySQL versione 3

  • Si è verificato un aumento dei dati in fase di elaborazione (numero di righe)?

  • Sono presenti più query in esecuzione contemporaneamente?

  • Sono state apportate modifiche allo schema o al database?

  • Sono stati rilevati difetti o correzioni del codice?

Indice

Parametri dell’host dell’istanza

Monitora le metriche dell’host dell’istanza come CPU, memoria e attività di rete per capire se è stata apportata una modifica del carico di lavoro. Esistono due concetti principali per comprendere le modifiche del carico di lavoro:

  • Utilizzo: utilizzo di un dispositivo, ad esempio CPU o disco. Può essere basato sul tempo o sulla capacità.

    • Basato sul tempo: la quantità di tempo in cui una risorsa è occupata in un determinato periodo di osservazione.

    • Basato sulla capacità: la quantità di throughput che un sistema o un componente è in grado di fornire, espressa in percentuale della sua capacità.

  • Saturazione: il grado in cui una risorsa richiede più lavoro di quanto ne possa elaborare. Quando l’utilizzo basato sulla capacità raggiunge il 100%, il lavoro aggiuntivo non può essere elaborato e deve essere messo in coda.

Utilizzo CPU

È possibile fare riferimento ai seguenti strumenti per identificare l’utilizzo e la saturazione della CPU:

  • CloudWatch fornisce la metrica CPUUtilization. Se raggiunge il 100%, l’istanza è satura. Tuttavia, le metriche di CloudWatch hanno una media di 1 minuto e mancano di granularità.

    Per ulteriori informazioni sui parametri di CloudWatch, consulta Parametri a livello di istanza per Amazon Aurora.

  • Monitoraggio avanzato fornisce le metriche restituite dal comando del sistema operativo top. Mostra le medie di carico e i seguenti stati della CPU, con una granularità di 1 secondo:

    • Idle (%) = Tempo di inattività

    • IRQ (%) = Interruzioni del software

    • Nice (%) = Periodo di tempo in cui i processi hanno una priorità nice.

    • Steal (%) = Tempo dedicato ad altri tenant (in relazione alla virtualizzazione)

    • System (%) = Orario sistema

    • User (%) = Orario utente

    • Wait (%) = Attesa I/O

    Per ulteriori informazioni sulle metriche di Monitoraggio avanzato, consulta Parametri del sistema operativo per Aurora.

Utilizzo della memoria

Se il sistema è sotto pressione in termini di memoria e il consumo di risorse sta raggiungendo la saturazione, si dovrebbe verificare un elevato grado di errori di scansione delle pagine, paginazione, scambio ed esaurimento della memoria delle pagine.

È possibile fare riferimento ai seguenti strumenti per identificare l’utilizzo e la saturazione della memoria:

CloudWatch fornisce la metrica FreeableMemory che mostra quanta memoria può essere recuperata svuotando alcune cache del sistema operativo e la memoria attualmente disponibile.

Per ulteriori informazioni sui parametri di CloudWatch, consulta Parametri a livello di istanza per Amazon Aurora.

Monitoraggio avanzato fornisce le seguenti metriche che possono aiutarti a identificare i problemi di utilizzo della memoria:

  • Buffers (KB): la quantità di memoria utilizzata per il buffering delle richieste di I/O prima della scrittura sul dispositivo di archiviazione, in kilobyte.

  • Cached (KB): la quantità di memoria utilizzata per la memorizzazione nella cache dell’I/O basato sul file system.

  • Free (KB): la quantità di memoria non assegnata, in kilobyte.

  • Swap: memorizzato nella cache, gratuito e totale.

Ad esempio, se vedi che l’istanza database utilizza memoria Swap, la quantità totale di memoria per il carico di lavoro è maggiore di quella attualmente disponibile sull’istanza. Ti consigliamo di aumentare le dimensioni dell’istanza database o di ottimizzare il carico di lavoro per utilizzare meno memoria.

Per ulteriori informazioni sulle metriche di Monitoraggio avanzato, consulta Parametri del sistema operativo per Aurora.

Per informazioni più dettagliate sull’utilizzo di Schema delle prestazioni e dello schema sys per determinare quali connessioni e componenti stanno utilizzando la memoria, consulta Risoluzione dei problemi di utilizzo della memoria per i database Aurora MySQL

Throughput di rete

CloudWatch fornisce le seguenti metriche per il throughput totale di rete, il tutto calcolato in media su 1 minuto:

  • NetworkReceiveThroughput: la quantità di throughput di rete ricevuto dai client da ogni istanza nel cluster di database Aurora.

  • NetworkTransmitThroughput: la quantità di throughput di rete inviato ai client da ogni istanza nel cluster di database Aurora.

  • NetworkThroughput: la quantità di throughput di rete ricevuto dai client e trasmesso agli stessi da ogni istanza nel cluster di database Aurora.

  • StorageNetworkReceiveThroughput: la quantità di throughput di rete ricevuto dal sottosistema di archiviazione Aurora mediante ogni istanza nel cluster di database.

  • StorageNetworkTransmitThroughput: la quantità di throughput di rete inviata al sottosistema di archiviazione Aurora mediante ogni istanza nel cluster di database Aurora.

  • StorageNetworkThroughput: la quantità di throughput di rete ricevuta dal sottosistema di archiviazione Aurora e inviata allo stesso mediante ogni istanza nel cluster di database Aurora.

Per ulteriori informazioni sui parametri di CloudWatch, consulta Parametri a livello di istanza per Amazon Aurora.

Monitoraggio avanzato fornisce i grafi network ricevuti (RX) e trasmessi (TX), con una granularità fino a 1 secondo.

Per ulteriori informazioni sulle metriche di Monitoraggio avanzato, consulta Parametri del sistema operativo per Aurora.

Parametri del database

Esamina le seguenti metriche CloudWatch per le modifiche del carico di lavoro:

  • BlockedTransactions: il numero medio di transazioni nel database bloccate ogni secondo.

  • BufferCacheHitRatio la percentuale di richieste gestite dalla cache del buffer.

  • CommitThroughput: il numero medio di operazioni di conferma al secondo.

  • DatabaseConnections: il numero di connessioni di rete client all’istanza del database.

  • Deadlocks: il numero medio di deadlock nel database al secondo.

  • DMLThroughput: il numero medio delle inserzioni, degli aggiornamenti e delle eliminazioni al secondo.

  • ResultSetCacheHitRatio: la percentuale di richieste gestite dalla cache del buffer.

  • RollbackSegmentHistoryListLength: i log di undo che registrano le transazioni sottoposte a commit con record contrassegnati per l’eliminazione.

  • RowLockTime: il tempo totale impiegato per l’acquisizione di blocchi di riga per le tabelle InnoDB.

  • SelectThroughput: numero medio di query di selezione al secondo.

Per ulteriori informazioni sui parametri di CloudWatch, consulta Parametri a livello di istanza per Amazon Aurora.

Considera le seguenti domande quando esamini il carico di lavoro:

  1. Sono state apportate modifiche recenti nella classe dell’istanza database, ad esempio la riduzione della dimensione dell’istanza da 8xlarge a 4xlarge o il passaggio da db.r5 a db.r6?

  2. È possibile creare un clone e riprodurre il problema o si verifica solo su quell’istanza?

  3. Si verifica un esaurimento delle risorse del server, un elevato esaurimento della CPU o della memoria? In caso affermativo, ciò potrebbe significare che è necessario hardware aggiuntivo.

  4. Una o più query richiedono più tempo?

  5. Le modifiche sono causate da un aggiornamento, in particolare da un aggiornamento della versione principale? In caso affermativo, confronta le metriche precedenti e successive all’aggiornamento.

  6. Sono state apportate modifiche al numero di istanze database di lettura?

  7. Hai abilitato la registrazione di log generali, di audit o binari? Per ulteriori informazioni, consulta Registrazione di log per i database Aurora MySQL.

  8. Hai abilitato, disabilitato o modificato l’uso della replica dei log binari (binlog)?

  9. Esistono transazioni di lunga durata che contengono un gran numero di blocchi di righe? Esamina la lunghezza dell’elenco della cronologia di InnoDB (HLL) per indicazioni di transazioni di lunga durata.

    Per ulteriori informazioni, consulta La lunghezza dell'elenco della cronologia di InnoDB è aumentata in modo significativo il post sul blog Why is my SELECT query running slowly on my Amazon Aurora MySQL DB cluster?

    1. Se un HLL di grandi dimensioni è causato da una transazione di scrittura, significa che i log UNDO si stanno accumulando (non vengono puliti regolarmente). In una transazione di scrittura di grandi dimensioni, questo accumulo può crescere rapidamente. In MySQL, UNDO è memorizzato nel tablespace SYSTEM. Il tablespace SYSTEM non è riducibile. Il log UNDO potrebbe far crescere il tablespace SYSTEM fino a diversi GB o addirittura TB. Dopo l’eliminazione, rilascia lo spazio allocato eseguendo un backup logico (dump) dei dati, quindi importa il dump in una nuova istanza database.

    2. Se un HLL di grandi dimensioni è causato da una transazione di lettura (query a esecuzione prolungata), può significare che la query sta utilizzando una grande quantità di spazio temporaneo. Rilascia lo spazio temporaneo riavviando. Esamina le metriche del database Approfondimenti sulle prestazioni per eventuali modifiche nella sezione Temp, ad esempio created_tmp_tables. Per ulteriori informazioni, consulta Monitoraggio del carico DB con Performance Insights su Amazon Aurora.

  10. È possibile suddividere le transazioni di lunga durata in transazioni più piccole che modificano un minor numero di righe?

  11. Ci sono cambiamenti nelle transazioni bloccate o aumenti delle situazioni di stallo? Esamina le metriche del database Approfondimenti sulle prestazioni per eventuali modifiche alle variabili di stato nella sezione Locks, ad esempio innodb_row_lock_time, innodb_row_lock_waits e innodb_dead_locks. Usa intervalli di 1 minuto o 5 minuti.

  12. I tempi di attesa sono aumentati? Esamina gli eventi e i tipi di attesa di Approfondimenti sulle prestazioni utilizzando intervalli di 1 minuto o 5 minuti. Analizza i principali eventi di attesa e verifica se sono correlati alle modifiche del carico di lavoro o ai conflitti del database. Ad esempio, buf_pool mutex indica la contesa del pool di buffer. Per ulteriori informazioni, consulta Regolazione di Aurora MySQL con eventi di attesa.