Risoluzione dei problemi relativi al carico di lavoro per i database Aurora My SQL - Amazon Aurora
Metriche relative all'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 relativi al carico di lavoro per i database Aurora My SQL

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 del 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 secondaria?

    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à in My SQL 8.0 e Variabili e opzioni di stato aggiunte, obsolete o rimosse in My SQL 8.0 nella documentazione La mia documentazione e. SQL Confronto tra Aurora My SQL versione 2 e Aurora My versione 3 SQL

  • C'è stato un aumento dei dati in fase di elaborazione (numero di righe)?

  • Ci sono più interrogazioni in esecuzione contemporaneamente?

  • Sono state apportate modifiche allo schema o al database?

  • Sono stati rilevati difetti o correzioni del codice?

Indice

Metriche relative all'host dell'istanza

Monitora le metriche relative all'host dell'istanzaCPU, ad esempio la memoria e l'attività di rete, per capire se c'è stata una modifica del carico di lavoro. Esistono due concetti principali per comprendere le modifiche del carico di lavoro:

  • Utilizzo: l'utilizzo di un dispositivo, ad esempio CPU un 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 velocità effettiva 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 di CPU

È possibile utilizzare i seguenti strumenti per identificare l'utilizzo e la saturazione: CPU

  • CloudWatch fornisce la CPUUtilization metrica. Se raggiunge il 100%, l'istanza è satura. Tuttavia, le CloudWatch metriche vengono calcolate in media su 1 minuto e mancano di granularità.

    Per ulteriori informazioni sulle metriche, consulta. CloudWatch Parametri a livello di istanza per Amazon Aurora

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

    • Idle (%)= Tempo di inattività

    • IRQ (%)= Interruzioni software

    • Nice (%)= Bel periodo per i processi con una buona priorità.

    • Steal (%)= Tempo dedicato al servizio di altri inquilini (legato alla virtualizzazione)

    • System (%)= Ora del sistema

    • User (%)= Ora dell'utente

    • Wait (%)= Attesa I/O

    Per ulteriori informazioni sulle metriche di Enhanced Monitoring, vedere. 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 osservare un elevato grado di scansione, paginazione, scambio ed errori delle pagine. out-of-memory

È possibile utilizzare i seguenti strumenti per identificare l'utilizzo e la saturazione della memoria:

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

Per ulteriori informazioni sulle metriche, consulta. CloudWatch Parametri a livello di istanza per Amazon Aurora

Enhanced Monitoring 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 storage, in kilobyte.

  • Cached (KB)— La quantità di memoria utilizzata per la memorizzazione nella cache degli I/O basati sul file system.

  • Free (KB)— La quantità di memoria non assegnata, espressa in kilobyte.

  • Swap— Memorizzata nella cache, gratuita e totale.

Ad esempio, se vedi che l'istanza DB utilizza Swap memoria, 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 DB o di ottimizzare il carico di lavoro per utilizzare meno memoria.

Per ulteriori informazioni sulle metriche di Enhanced Monitoring, consulta. Parametri del sistema operativo per Aurora

Per informazioni più dettagliate sull'utilizzo dello schema e sys dello schema delle prestazioni per determinare quali connessioni e componenti utilizzano la memoria, vedereRisoluzione dei problemi di utilizzo della memoria per i database Aurora MySQL.

Throughput di rete

CloudWatch fornisce le seguenti metriche per la velocità di trasmissione totale della rete, tutte calcolate in media su 1 minuto:

  • NetworkReceiveThroughput— La quantità di throughput di rete ricevuta dai client da ciascuna istanza nel cluster Aurora DB.

  • NetworkTransmitThroughput— La quantità di throughput di rete inviata ai client da ciascuna istanza nel cluster Aurora DB.

  • NetworkThroughput— La quantità di throughput di rete ricevuta e trasmessa ai client da ciascuna istanza del cluster Aurora DB.

  • StorageNetworkReceiveThroughput— La quantità di throughput di rete ricevuta dal sottosistema di archiviazione Aurora da ciascuna istanza del cluster DB.

  • StorageNetworkTransmitThroughput— La quantità di throughput di rete inviata al sottosistema di archiviazione Aurora da ciascuna istanza del cluster Aurora DB.

  • StorageNetworkThroughput— La quantità di throughput di rete ricevuta e inviata al sottosistema di archiviazione Aurora da ciascuna istanza del cluster Aurora DB.

Per ulteriori informazioni sulle metriche, consulta. CloudWatch Parametri a livello di istanza per Amazon Aurora

Enhanced Monitoring fornisce i grafici network ricevuti (RX) e trasmessi (TX), con una granularità fino a 1 secondo.

Per ulteriori informazioni sulle metriche di Enhanced Monitoring, consulta. Parametri del sistema operativo per Aurora

Parametri del database

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

  • BlockedTransactions— Il numero medio di transazioni bloccate nel database al secondo.

  • BufferCacheHitRatio— La percentuale di richieste servite dalla buffer cache.

  • CommitThroughput— Il numero medio di operazioni di commit al secondo.

  • DatabaseConnections— Il numero di connessioni di rete del client all'istanza del database.

  • Deadlocks— Il numero medio di deadlock nel database al secondo.

  • DMLThroughput— Il numero medio di inserimenti, aggiornamenti ed eliminazioni al secondo.

  • ResultSetCacheHitRatio— La percentuale di richieste servite dalla cache delle query.

  • RollbackSegmentHistoryListLength— I registri di annullamento che registrano le transazioni impegnate con record contrassegnati da eliminare.

  • RowLockTime— Il tempo totale impiegato per l'acquisizione di blocchi di riga per le tabelle InnoDB.

  • SelectThroughput— Il numero medio di query selezionate al secondo.

Per ulteriori informazioni sulle CloudWatch metriche, vedere. Parametri a livello di istanza per Amazon Aurora

Considerate le seguenti domande quando esaminate il carico di lavoro:

  1. Sono state apportate modifiche recenti nella classe dell'istanza DB, 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. C'è un esaurimento delle risorse del server, un elevato CPU o un esaurimento della memoria? In caso affermativo, ciò potrebbe significare che è necessario hardware aggiuntivo.

  4. Una o più domande 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 DB di Reader?

  7. Hai abilitato la registrazione generale, di controllo o binaria? Per ulteriori informazioni, consulta Registrazione 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 con un gran numero di blocchi di righe? Esamina la lunghezza dell'elenco della cronologia di InnoDB (HLL) per le indicazioni sulle transazioni di lunga durata.

    Per ulteriori informazioni, consulta La lunghezza dell'elenco della cronologia di InnoDB è aumentata in modo significativo il post sul blog Perché la mia SELECT query viene eseguita lentamente sul mio cluster Amazon Aurora My SQL DB? .

    1. Se un errore di grandi dimensioni HLL è causato da una transazione di scrittura, significa che UNDO i log si accumulano (non vengono puliti regolarmente). In una transazione di scrittura di grandi dimensioni, questo accumulo può crescere rapidamente. In MySQL, UNDO viene memorizzato nel SYSTEMtablespace. Il SYSTEM tablespace non è restringibile. Il UNDO log potrebbe far crescere il SYSTEM tablespace 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 DB.

    2. Se un errore di grandi dimensioni HLL è 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 di Performance Insights DB per eventuali modifiche nella Temp sezione, ad esempiocreated_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 di Performance Insights DB per eventuali modifiche alle variabili di stato nella Locks sezione, ad esempio innodb_row_lock_time innodb_row_lock_waits, e innodb_dead_locks. Utilizza intervalli di 1 minuto o 5 minuti.

  12. I tempi di attesa sono aumentati? Esamina gli eventi di attesa e i tipi di attesa di Performance Insights 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.