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 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, vedere Novità di MySQL
8.0 e Variabili e opzioni di stato aggiunte, obsolete o rimosse in MySQL 8.0 nella documentazione di MySQL e. Confronto tra Aurora MySQL versione 2 e Aurora MySQL versione 3 -
C'è stato un aumento dei dati elaborati (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 dell'host dell'istanza, come CPU, memoria e 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: 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 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 CPU
È possibile utilizzare i seguenti strumenti per identificare l'utilizzo e la saturazione della CPU:
-
CloudWatch fornisce la
CPUUtilizationmetrica. 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
topoperativo. 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 (%)= Bel periodo per i processi con una buona priorità. -
Steal (%)= Tempo impiegato a servire 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:
-
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?
-
È possibile creare un clone e riprodurre il problema o si verifica solo su quell'istanza?
-
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.
-
Una o più domande richiedono più tempo?
-
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.
-
Sono state apportate modifiche al numero di istanze DB di Reader?
-
Hai abilitato la registrazione generale, di controllo o binaria? Per ulteriori informazioni, consulta Registrazione per i database Aurora MySQL.
-
Hai abilitato, disabilitato o modificato l'uso della replica dei log binari (binlog)?
-
Esistono transazioni di lunga durata con 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 Perché la mia query SELECT viene eseguita lentamente sul mio cluster Amazon Aurora MySQL DB
? . -
Se un HLL di grandi dimensioni è causato da una transazione di scrittura, significa che
UNDOi log si stanno accumulando (non vengono puliti regolarmente). In una transazione di scrittura di grandi dimensioni, questo accumulo può crescere rapidamente. In MySQLUNDO, è memorizzato nel tablespace SYSTEM.Il SYSTEMtablespace non è riducibile. IlUNDOlog potrebbe far crescere ilSYSTEMtablespace 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. -
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 di Performance Insights DB per eventuali modifiche nella
Tempsezione, ad esempiocreated_tmp_tables. Per ulteriori informazioni, consulta Monitoraggio del carico DB con Performance Insights su Amazon Aurora.
-
-
È possibile suddividere le transazioni di lunga durata in transazioni più piccole che modificano un minor numero di righe?
-
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
Lockssezione, ad esempioinnodb_row_lock_timeinnodb_row_lock_waits, einnodb_dead_locks. Utilizza intervalli di 1 minuto o 5 minuti. -
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 mutexindica la contesa del pool di buffer. Per ulteriori informazioni, consulta Regolazione di Aurora MySQL con eventi di attesa.
Risoluzione dei problemi di utilizzo della memoria per i database Aurora MySQL
Sebbene CloudWatch Enhanced Monitoring e Performance Insights forniscano una buona panoramica dell'utilizzo della memoria a livello di sistema operativo, ad esempio la quantità di memoria utilizzata dal processo del database, non consentono di analizzare quali connessioni o componenti all'interno del motore potrebbero causare questo utilizzo di memoria.
Per risolvere questo problema, è possibile utilizzare lo schema e sys lo schema delle prestazioni. In Aurora MySQL versione 3, la strumentazione di memoria è abilitata per impostazione predefinita quando lo schema delle prestazioni è abilitato. In Aurora MySQL versione 2, per impostazione predefinita è abilitata solo la strumentazione di memoria per l'utilizzo della memoria Performance Schema. Per informazioni sulle tabelle disponibili nello schema delle prestazioni per tenere traccia dell'utilizzo della memoria e abilitare la strumentazione di memoria dello schema di prestazioni, vedere Tabelle di riepilogo della memoria
Sebbene nello schema delle prestazioni siano disponibili informazioni dettagliate per tenere traccia dell'utilizzo corrente della memoria, lo schema sys di MySQL
Nello sys schema, sono disponibili le seguenti viste per tenere traccia dell'utilizzo della memoria per connessione, componente e query.
| Vista | Descrizione |
|---|---|
|
Fornisce informazioni sull'utilizzo della memoria del motore da parte dell'host. Ciò può essere utile per identificare quali server applicativi o host client stanno consumando memoria. |
|
|
Fornisce informazioni sull'utilizzo della memoria del motore in base all'ID del thread. L'ID del thread in MySQL può essere una connessione client o un thread in background. È possibile mappare gli ID dei thread agli ID di connessione MySQL utilizzando la vista sys.processlist o la |
|
|
Fornisce informazioni sull'utilizzo della memoria del motore da parte dell'utente. Ciò può essere utile per identificare quali account utente o client stanno consumando memoria. |
|
|
Fornisce informazioni sull'utilizzo della memoria del motore per componente del motore. Ciò può essere utile per identificare l'utilizzo della memoria a livello globale in base ai buffer o ai componenti del motore. Ad esempio, potresti vedere l' |
|
|
Fornisce una panoramica dell'utilizzo totale della memoria tracciata nel motore di database. |
In Aurora MySQL versione 3.05 e successive, puoi anche tenere traccia dell'utilizzo massimo della memoria tramite statement digest nelle tabelle di riepilogo delle istruzioni Performance Schema.MAX_TOTAL_MEMORY colonna può aiutarti a identificare la quantità massima di memoria utilizzata da Query Digest dall'ultima reimpostazione delle statistiche o dal riavvio dell'istanza del database. Ciò può essere utile per identificare query specifiche che potrebbero consumare molta memoria.
Nota
Lo schema e lo sys schema delle prestazioni mostrano l'utilizzo corrente della memoria sul server e i livelli massimi di memoria consumata per ogni componente del motore e della connessione. Poiché lo schema delle prestazioni viene mantenuto in memoria, le informazioni vengono reimpostate al riavvio dell'istanza DB. Per mantenere una cronologia nel tempo, si consiglia di configurare il recupero e l'archiviazione di questi dati al di fuori dello schema delle prestazioni.
Argomenti
Esempio 1: utilizzo continuo ed elevato della memoria
Guardando FreeableMemory a livello globale CloudWatch, possiamo vedere che l'utilizzo della memoria è aumentato notevolmente alle 02:59 UTC del 26/03/2020.
Questo non ci dice il quadro completo. Per determinare quale componente utilizza più memoria, puoi accedere al database e guardaresys.memory_global_by_current_bytes. Questa tabella contiene un elenco di eventi di memoria che MySQL tiene traccia, insieme a informazioni sull'allocazione della memoria per evento. Ogni evento di tracciamento della memoria inizia conmemory/%, seguito da altre informazioni sul componente/funzionalità del motore a cui è associato l'evento.
Ad esempio, memory/performance_schema/% è per gli eventi di memoria relativi allo schema delle prestazioni, memory/innodb/% è per InnoDB e così via. Per ulteriori informazioni sulle convenzioni di denominazione degli eventi, vedere Convenzioni di denominazione degli strumenti Performance Schema nella documentazione MySQL
Dalla seguente interrogazione, possiamo trovare il probabile colpevole in base acurrent_alloc, ma possiamo anche vedere molti eventi. memory/performance_schema/%
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10; +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB | | memory/performance_schema/prepared_statements_instances | 252 | 488.25 MiB | 1.94 MiB | 252 | 488.25 MiB | 1.94 MiB | | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 1028 | 52.27 MiB | 52.06 KiB | 1028 | 52.27 MiB | 52.06 KiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 4 | 47.25 MiB | 11.81 MiB | 4 | 47.25 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB | | memory/performance_schema/memory_summary_by_thread_by_event_name | 4 | 31.64 MiB | 7.91 MiB | 4 | 31.64 MiB | 7.91 MiB | | memory/innodb/memory | 15227 | 27.44 MiB | 1.85 KiB | 20619 | 33.33 MiB | 1.66 KiB | | memory/sql/String::value | 74411 | 21.85 MiB | 307 bytes | 76867 | 25.54 MiB | 348 bytes | | memory/sql/TABLE | 8381 | 21.03 MiB | 2.57 KiB | 8381 | 21.03 MiB | 2.57 KiB | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.02 sec)
Abbiamo detto in precedenza che lo schema delle prestazioni è archiviato in memoria, il che significa che viene anche registrato nella strumentazione di memoria. performance_schema
Nota
Se riscontri che il Performance Schema utilizza molta memoria e desideri limitarne l'utilizzo, puoi regolare i parametri del database in base alle tue esigenze. Per ulteriori informazioni, vedere Il modello di allocazione della memoria Performance Schema
Per motivi di leggibilità, è possibile eseguire nuovamente la stessa query ma escludere gli eventi di Performance Schema. L'output mostra quanto segue:
-
Il principale consumatore di memoria è
memory/sql/Prepared_statement::main_mem_root. -
La
current_alloccolonna ci dice che MySQL ha 4,91 GiB attualmente assegnati a questo evento. -
Ci
high_alloc columndice che 4,91 GiB è il limite massimo dall'ultima reimpostazionecurrent_allocdelle statistiche o dal riavvio del server. Ciò significa chememory/sql/Prepared_statement::main_mem_rootè al suo valore massimo.
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name NOT LIKE 'memory/performance_schema/%' LIMIT 10; +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB | | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/innodb/memory | 17096 | 31.68 MiB | 1.90 KiB | 22498 | 37.60 MiB | 1.71 KiB | | memory/sql/String::value | 122277 | 27.94 MiB | 239 bytes | 124699 | 29.47 MiB | 247 bytes | | memory/sql/TABLE | 9927 | 24.67 MiB | 2.55 KiB | 9929 | 24.68 MiB | 2.55 KiB | | memory/innodb/lock0lock | 8888 | 19.71 MiB | 2.27 KiB | 8888 | 19.71 MiB | 2.27 KiB | | memory/sql/Prepared_statement::infrastructure | 257623 | 16.24 MiB | 66 bytes | 257631 | 16.24 MiB | 66 bytes | | memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB | | memory/innodb/sync0arr | 3 | 7.03 MiB | 2.34 MiB | 3 | 7.03 MiB | 2.34 MiB | | memory/sql/THD::main_mem_root | 815 | 6.56 MiB | 8.24 KiB | 849 | 7.19 MiB | 8.67 KiB | +-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.06 sec)
Dal nome dell'evento, possiamo dire che questa memoria viene utilizzata per le dichiarazioni preparate. Se vuoi vedere quali connessioni utilizzano questa memoria, puoi controllare memory_by_thread_by_current_bytes
Nell'esempio seguente, a ogni connessione sono allocati circa 7 MiB, con un limite massimo di circa 6,29 MiB (). current_max_alloc Ciò ha senso, perché l'esempio utilizza 80 tabelle e 800 sysbench connessioni con istruzioni preparate. Se si desidera ridurre l'utilizzo della memoria in questo scenario, è possibile ottimizzare l'utilizzo da parte dell'applicazione delle istruzioni preparate per ridurre il consumo di memoria.
mysql> SELECT * FROM sys.memory_by_thread_by_current_bytes; +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ | thread_id | user | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated | +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ | 46 | rdsadmin@localhost | 405 | 8.47 MiB | 21.42 KiB | 8.00 MiB | 155.86 MiB | | 61 | reinvent@10.0.4.4 | 1749 | 6.72 MiB | 3.93 KiB | 6.29 MiB | 14.24 MiB | | 101 | reinvent@10.0.4.4 | 1845 | 6.71 MiB | 3.72 KiB | 6.29 MiB | 14.50 MiB | | 55 | reinvent@10.0.4.4 | 1674 | 6.68 MiB | 4.09 KiB | 6.29 MiB | 14.13 MiB | | 57 | reinvent@10.0.4.4 | 1416 | 6.66 MiB | 4.82 KiB | 6.29 MiB | 13.52 MiB | | 112 | reinvent@10.0.4.4 | 1759 | 6.66 MiB | 3.88 KiB | 6.29 MiB | 14.17 MiB | | 66 | reinvent@10.0.4.4 | 1428 | 6.64 MiB | 4.76 KiB | 6.29 MiB | 13.47 MiB | | 75 | reinvent@10.0.4.4 | 1389 | 6.62 MiB | 4.88 KiB | 6.29 MiB | 13.40 MiB | | 116 | reinvent@10.0.4.4 | 1333 | 6.61 MiB | 5.08 KiB | 6.29 MiB | 13.21 MiB | | 90 | reinvent@10.0.4.4 | 1448 | 6.59 MiB | 4.66 KiB | 6.29 MiB | 13.58 MiB | | 98 | reinvent@10.0.4.4 | 1440 | 6.57 MiB | 4.67 KiB | 6.29 MiB | 13.52 MiB | | 94 | reinvent@10.0.4.4 | 1433 | 6.57 MiB | 4.69 KiB | 6.29 MiB | 13.49 MiB | | 62 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.48 MiB | | 87 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.25 MiB | | 99 | reinvent@10.0.4.4 | 1346 | 6.54 MiB | 4.98 KiB | 6.29 MiB | 13.24 MiB | | 105 | reinvent@10.0.4.4 | 1347 | 6.54 MiB | 4.97 KiB | 6.29 MiB | 13.34 MiB | | 73 | reinvent@10.0.4.4 | 1335 | 6.54 MiB | 5.02 KiB | 6.29 MiB | 13.23 MiB | | 54 | reinvent@10.0.4.4 | 1510 | 6.53 MiB | 4.43 KiB | 6.29 MiB | 13.49 MiB | . . . . . . | 812 | reinvent@10.0.4.4 | 1259 | 6.38 MiB | 5.19 KiB | 6.29 MiB | 13.05 MiB | | 214 | reinvent@10.0.4.4 | 1279 | 6.38 MiB | 5.10 KiB | 6.29 MiB | 12.90 MiB | | 325 | reinvent@10.0.4.4 | 1254 | 6.38 MiB | 5.21 KiB | 6.29 MiB | 12.99 MiB | | 705 | reinvent@10.0.4.4 | 1273 | 6.37 MiB | 5.13 KiB | 6.29 MiB | 13.03 MiB | | 530 | reinvent@10.0.4.4 | 1268 | 6.37 MiB | 5.15 KiB | 6.29 MiB | 12.92 MiB | | 307 | reinvent@10.0.4.4 | 1263 | 6.37 MiB | 5.17 KiB | 6.29 MiB | 12.87 MiB | | 738 | reinvent@10.0.4.4 | 1260 | 6.37 MiB | 5.18 KiB | 6.29 MiB | 13.00 MiB | | 819 | reinvent@10.0.4.4 | 1252 | 6.37 MiB | 5.21 KiB | 6.29 MiB | 13.01 MiB | | 31 | innodb/srv_purge_thread | 17810 | 3.14 MiB | 184 bytes | 2.40 MiB | 205.69 MiB | | 38 | rdsadmin@localhost | 599 | 1.76 MiB | 3.01 KiB | 1.00 MiB | 25.58 MiB | | 1 | sql/main | 3756 | 1.32 MiB | 367 bytes | 355.78 KiB | 6.19 MiB | | 854 | rdsadmin@localhost | 46 | 1.08 MiB | 23.98 KiB | 1.00 MiB | 5.10 MiB | | 30 | innodb/clone_gtid_thread | 1596 | 573.14 KiB | 367 bytes | 254.91 KiB | 970.69 KiB | | 40 | rdsadmin@localhost | 235 | 245.19 KiB | 1.04 KiB | 128.88 KiB | 808.64 KiB | | 853 | rdsadmin@localhost | 96 | 94.63 KiB | 1009 bytes | 29.73 KiB | 422.45 KiB | | 36 | rdsadmin@localhost | 33 | 36.29 KiB | 1.10 KiB | 16.08 KiB | 74.15 MiB | | 33 | sql/event_scheduler | 3 | 16.27 KiB | 5.42 KiB | 16.04 KiB | 16.27 KiB | | 35 | sql/compress_gtid_table | 8 | 14.20 KiB | 1.77 KiB | 8.05 KiB | 18.62 KiB | | 25 | innodb/fts_optimize_thread | 12 | 1.86 KiB | 158 bytes | 648 bytes | 1.98 KiB | | 23 | innodb/srv_master_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 24.40 KiB | | 24 | innodb/dict_stats_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 1.35 KiB | | 5 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes | | 6 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes | | 2 | sql/aws_oscar_log_level_monitor | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 4 | innodb/io_ibuf_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 7 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 8 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 9 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 10 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 11 | innodb/srv_lra_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 12 | innodb/srv_akp_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 18 | innodb/srv_lock_timeout_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 248 bytes | | 19 | innodb/srv_error_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 20 | innodb/srv_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 21 | innodb/buf_resize_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 22 | innodb/btr_search_sys_toggle_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 32 | innodb/dict_persist_metadata_table_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | | 34 | sql/signal_handler | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes | +-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+ 831 rows in set (2.48 sec)
Come accennato in precedenza, il valore dell'ID del thread (thd_id) qui può riferirsi ai thread in background del server o alle connessioni al database. Se vuoi mappare i valori degli ID dei thread agli ID di connessione al database, puoi usare la performance_schema.threads tabella o la sys.processlist vista, conn_id dov'è l'ID di connessione.
mysql> SELECT thd_id,conn_id,user,db,command,state,time,last_wait FROM sys.processlist WHERE user='reinvent@10.0.4.4'; +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ | thd_id | conn_id | user | db | command | state | time | last_wait | +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ | 590 | 562 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 578 | 550 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 579 | 551 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 580 | 552 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 581 | 553 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 582 | 554 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 583 | 555 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 584 | 556 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 585 | 557 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 586 | 558 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 587 | 559 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | . . . . . . | 323 | 295 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle | | 324 | 296 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 325 | 297 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush | | 326 | 298 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler | | 438 | 410 | reinvent@10.0.4.4 | sysbench | Execute | System lock | 0 | wait/lock/table/sql/handler | | 280 | 252 | reinvent@10.0.4.4 | sysbench | Sleep | starting | 0 | wait/io/socket/sql/client_connection | | 98 | 70 | reinvent@10.0.4.4 | sysbench | Query | freeing items | 0 | NULL | +--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+ 804 rows in set (5.51 sec)
Ora interrompiamo il sysbench carico di lavoro, che chiude le connessioni e libera la memoria. Ricontrollando gli eventi, possiamo confermare che la memoria è stata liberata, ma ci dice high_alloc comunque qual è il limite massimo. La high_alloc colonna può essere molto utile per identificare brevi picchi di utilizzo della memoria, dai quali potrebbe non essere possibile identificare immediatamente l'utilizzocurrent_alloc, poiché mostra solo la memoria attualmente allocata.
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10; +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 512823 | 4.91 GiB | 10.04 KiB | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 1 row in set (0.00 sec)
Se si desidera eseguire il ripristinohigh_alloc, è possibile troncare le tabelle di riepilogo della performance_schema memoria, ma ciò ripristina tutta la strumentazione della memoria. Per ulteriori informazioni, vedere le caratteristiche generali della tabella dello schema delle prestazioni
Nell'esempio seguente, possiamo vedere che high_alloc viene ripristinato dopo il troncamento.
mysql> TRUNCATE `performance_schema`.`memory_summary_global_by_event_name`; Query OK, 0 rows affected (0.00 sec) mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10; +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 17 | 253.80 KiB | 14.93 KiB | +----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 1 row in set (0.00 sec)
Esempio 2: picchi di memoria transitori
Un altro evento comune sono i brevi picchi di utilizzo della memoria su un server di database. Possono trattarsi di cadute periodiche della memoria liberabilesys.memory_global_by_current_bytes, difficili da risolvere current_alloc in quanto la memoria è già stata liberata.
Nota
Se le statistiche dello schema delle prestazioni sono state reimpostate o l'istanza del database è stata riavviata, queste informazioni non saranno disponibili in o p. sys erformance_schema Per conservare queste informazioni, ti consigliamo di configurare la raccolta di metriche esterne.
Il seguente grafico della os.memory.free metrica di Enhanced Monitoring mostra brevi picchi di 7 secondi nell'utilizzo della memoria. Enhanced Monitoring consente di eseguire il monitoraggio a intervalli di appena 1 secondo, il che è perfetto per rilevare picchi transitori come questi.
Per aiutare a diagnosticare la causa dell'utilizzo della memoria, possiamo utilizzare una combinazione di visualizzazioni di riepilogo della sys memoria e tabelle di high_alloc riepilogo delle istruzioni del Performance Schema per cercare di identificare le sessioni e le
Come previsto, poiché l'utilizzo della memoria non è attualmente elevato, nella visualizzazione sys dello schema sottostante non è possibile individuare i principali autori di violazioni. current_alloc
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10; +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ | memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB | | memory/innodb/os0event | 439372 | 60.34 MiB | 144 bytes | 439372 | 60.34 MiB | 144 bytes | | memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB | | memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB | | memory/performance_schema/events_statements_history_long | 1 | 14.34 MiB | 14.34 MiB | 1 | 14.34 MiB | 14.34 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 257 | 13.07 MiB | 52.06 KiB | 257 | 13.07 MiB | 52.06 KiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 1 | 11.81 MiB | 11.81 MiB | 1 | 11.81 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.sql_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB | +-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+ 10 rows in set (0.01 sec)
Espandendo la visualizzazione in base all'ordinehigh_alloc, ora possiamo vedere che il memory/temptable/physical_ram componente è un ottimo candidato in questo caso. Al suo massimo, ha consumato 515,00 MiB.
Come suggerisce il nome, l'utilizzo della memoria memory/temptable/physical_ram degli strumenti per il motore di TEMP archiviazione in MySQL, introdotto in MySQL 8.0. Per ulteriori informazioni su come MySQL utilizza le tabelle temporanee, vedere Uso interno delle tabelle temporanee in MySQL nella documentazione di MySQL
Nota
Stiamo usando la vista in questo esempio. sys.x$memory_global_by_current_bytes
mysql> SELECT event_name, format_bytes(current_alloc) AS "currently allocated", sys.format_bytes(high_alloc) AS "high-water mark" FROM sys.x$memory_global_by_current_bytes ORDER BY high_alloc DESC LIMIT 10; +-----------------------------------------------------------------------------+---------------------+-----------------+ | event_name | currently allocated | high-water mark | +-----------------------------------------------------------------------------+---------------------+-----------------+ | memory/temptable/physical_ram | 4.00 MiB | 515.00 MiB | | memory/innodb/hash0hash | 79.07 MiB | 79.07 MiB | | memory/innodb/os0event | 63.95 MiB | 63.95 MiB | | memory/performance_schema/events_statements_summary_by_digest | 40.28 MiB | 40.28 MiB | | memory/mysys/KEY_CACHE | 16.00 MiB | 16.00 MiB | | memory/performance_schema/events_statements_history_long | 14.34 MiB | 14.34 MiB | | memory/performance_schema/events_errors_summary_by_thread_by_error | 13.07 MiB | 13.07 MiB | | memory/performance_schema/events_statements_summary_by_thread_by_event_name | 11.81 MiB | 11.81 MiB | | memory/performance_schema/events_statements_summary_by_digest.digest_text | 9.77 MiB | 9.77 MiB | | memory/performance_schema/events_statements_history_long.sql_text | 9.77 MiB | 9.77 MiB | +-----------------------------------------------------------------------------+---------------------+-----------------+ 10 rows in set (0.00 sec)
NelEsempio 1: utilizzo continuo ed elevato della memoria, abbiamo controllato l'utilizzo corrente della memoria per ogni connessione per determinare quale connessione è responsabile dell'utilizzo della memoria in questione. In questo esempio, la memoria è già stata liberata, quindi non è utile controllare l'utilizzo della memoria per le connessioni correnti.
Per approfondire e trovare le dichiarazioni, gli utenti e gli host offensivi, utilizziamo lo schema delle prestazioni. Lo schema delle prestazioni contiene più tabelle di riepilogo delle istruzioni suddivise in diverse dimensioni, come nome dell'evento, statement digest, host, thread e utente. Ogni visualizzazione ti consentirà di approfondire dove vengono eseguite determinate istruzioni e cosa stanno facendo. Questa sezione è dedicata aMAX_TOTAL_MEMORY, ma è possibile trovare ulteriori informazioni su tutte le colonne disponibili nella documentazione delle tabelle di riepilogo delle istruzioni dello schema delle prestazioni
mysql> SHOW TABLES IN performance_schema LIKE 'events_statements_summary_%'; +------------------------------------------------------------+ | Tables_in_performance_schema (events_statements_summary_%) | +------------------------------------------------------------+ | events_statements_summary_by_account_by_event_name | | events_statements_summary_by_digest | | events_statements_summary_by_host_by_event_name | | events_statements_summary_by_program | | events_statements_summary_by_thread_by_event_name | | events_statements_summary_by_user_by_event_name | | events_statements_summary_global_by_event_name | +------------------------------------------------------------+ 7 rows in set (0.00 sec)
Per prima cosa controlliamo events_statements_summary_by_digest per vedereMAX_TOTAL_MEMORY.
Da ciò possiamo vedere quanto segue:
-
La query con digest
20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4asembra essere un buon candidato per questo utilizzo della memoria. IlMAX_TOTAL_MEMORYnumero è 537450710, che corrisponde al picco massimo registrato durante l'evento.memory/temptable/physical_ramsys.x$memory_global_by_current_bytes -
È stato eseguito quattro volte (
COUNT_STAR), la prima alle 04:08:34.943 256 del 26/03/2020 e l'ultima alle 04:43:06.998 310 del 2024-03-26.
mysql> SELECT SCHEMA_NAME,DIGEST,COUNT_STAR,MAX_TOTAL_MEMORY,FIRST_SEEN,LAST_SEEN FROM performance_schema.events_statements_summary_by_digest ORDER BY MAX_TOTAL_MEMORY DESC LIMIT 5; +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ | SCHEMA_NAME | DIGEST | COUNT_STAR | MAX_TOTAL_MEMORY | FIRST_SEEN | LAST_SEEN | +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ | sysbench | 20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a | 4 | 537450710 | 2024-03-26 04:08:34.943256 | 2024-03-26 04:43:06.998310 | | NULL | f158282ea0313fefd0a4778f6e9b92fc7d1e839af59ebd8c5eea35e12732c45d | 4 | 3636413 | 2024-03-26 04:29:32.712348 | 2024-03-26 04:36:26.269329 | | NULL | 0046bc5f642c586b8a9afd6ce1ab70612dc5b1fd2408fa8677f370c1b0ca3213 | 2 | 3459965 | 2024-03-26 04:31:37.674008 | 2024-03-26 04:32:09.410718 | | NULL | 8924f01bba3c55324701716c7b50071a60b9ceaf17108c71fd064c20c4ab14db | 1 | 3290981 | 2024-03-26 04:31:49.751506 | 2024-03-26 04:31:49.751506 | | NULL | 90142bbcb50a744fcec03a1aa336b2169761597ea06d85c7f6ab03b5a4e1d841 | 1 | 3131729 | 2024-03-26 04:15:09.719557 | 2024-03-26 04:15:09.719557 | +-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+ 5 rows in set (0.00 sec)
Ora che conosciamo il digest incriminato, possiamo ottenere maggiori dettagli come il testo della query, l'utente che l'ha eseguita e dove è stata eseguita. In base al testo del digest restituito, possiamo vedere che si tratta di un'espressione di tabella comune (CTE) che crea quattro tabelle temporanee ed esegue quattro scansioni di tabelle, il che è molto inefficiente.
mysql> SELECT SCHEMA_NAME,DIGEST_TEXT,QUERY_SAMPLE_TEXT,MAX_TOTAL_MEMORY,SUM_ROWS_SENT,SUM_ROWS_EXAMINED,SUM_CREATED_TMP_TABLES,SUM_NO_INDEX_USED FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST='20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a'\G; *************************** 1. row *************************** SCHEMA_NAME: sysbench DIGEST_TEXT: WITH RECURSIVE `cte` ( `n` ) AS ( SELECT ? FROM `sbtest1` UNION ALL SELECT `id` + ? FROM `sbtest1` ) SELECT * FROM `cte` QUERY_SAMPLE_TEXT: WITH RECURSIVE cte (n) AS ( SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte MAX_TOTAL_MEMORY: 537450710 SUM_ROWS_SENT: 80000000 SUM_ROWS_EXAMINED: 80000000 SUM_CREATED_TMP_TABLES: 4 SUM_NO_INDEX_USED: 4 1 row in set (0.01 sec)
Per ulteriori informazioni sulla events_statements_summary_by_digest tabella e su altre tabelle di riepilogo delle istruzioni Performance Schema, vedere Tabelle di riepilogo delle dichiarazioni
Puoi anche eseguire un'istruzione EXPLAIN o EXPLAIN
Nota
EXPLAIN ANALYZEpuò fornire più informazioni diEXPLAIN, ma esegue anche la query, quindi fai attenzione.
-- EXPLAIN mysql> EXPLAIN WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte; +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ | 1 | PRIMARY | <derived2> | NULL | ALL | NULL | NULL | NULL | NULL | 19221520 | 100.00 | NULL | | 2 | DERIVED | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index | | 3 | UNION | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index | +----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+ 3 rows in set, 1 warning (0.00 sec) -- EXPLAIN format=tree mysql> EXPLAIN format=tree WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G; *************************** 1. row *************************** EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) -> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) -> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) -> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) 1 row in set (0.00 sec) -- EXPLAIN ANALYZE mysql> EXPLAIN ANALYZE WITH RECURSIVE cte (n) AS (SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G; *************************** 1. row *************************** EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) (actual time=6666..9201 rows=20e+6 loops=1) -> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) (actual time=6666..6666 rows=20e+6 loops=1) -> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0365..2006 rows=10e+6 loops=1) -> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0311..2494 rows=10e+6 loops=1) 1 row in set (10.53 sec)
Ma chi lo gestiva? Possiamo vedere nello schema delle prestazioni che l'destructive_operatorutente aveva MAX_TOTAL_MEMORY di 537450710, che corrisponde ancora una volta ai risultati precedenti.
Nota
Lo schema delle prestazioni è archiviato in memoria, quindi non deve essere considerato l'unica fonte per il controllo. Se è necessario mantenere una cronologia delle istruzioni eseguite e da quali utenti, si consiglia di abilitare la registrazione di controllo. Se è inoltre necessario conservare informazioni sull'utilizzo della memoria, si consiglia di configurare il monitoraggio per esportare e archiviare questi valori.
mysql> SELECT USER,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_user_by_event_name ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5; +----------------------+---------------------------+------------+------------------+ | USER | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY | +----------------------+---------------------------+------------+------------------+ | destructive_operator | statement/sql/select | 4 | 537450710 | | rdsadmin | statement/sql/select | 4172 | 3290981 | | rdsadmin | statement/sql/show_tables | 2 | 3615821 | | rdsadmin | statement/sql/show_fields | 2 | 3459965 | | rdsadmin | statement/sql/show_status | 75 | 1914976 | +----------------------+---------------------------+------------+------------------+ 5 rows in set (0.00 sec) mysql> SELECT HOST,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_host_by_event_name WHERE HOST != 'localhost' AND COUNT_STAR>0 ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5; +------------+----------------------+------------+------------------+ | HOST | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY | +------------+----------------------+------------+------------------+ | 10.0.8.231 | statement/sql/select | 4 | 537450710 | +------------+----------------------+------------+------------------+ 1 row in set (0.00 sec)
Risoluzione dei out-of-memory problemi relativi ai database Aurora MySQL
Il parametro a livello di istanza aurora_oom_response di Aurora MySQL può consentire all'istanza database di monitorare la memoria di sistema e stimare la memoria utilizzata da varie istruzioni e connessioni. Se la memoria del sistema sta esaurendo, può eseguire un elenco di azioni per tentare di liberare quella memoria. Lo fa nel tentativo di evitare il riavvio del database a causa di problemi out-of-memory (OOM). Il parametro a livello di istanza esegue una serie di azioni separate da virgole eseguite da un'istanza DB quando la memoria è scarsa. Il aurora_oom_response parametro è supportato per le versioni 2 e 3 di Aurora MySQL.
Per il parametro è possibile utilizzare i seguenti valori e combinazioni di essi. aurora_oom_response Una stringa vuota indica che non viene intrapresa alcuna azione e disattiva di fatto la funzionalità, lasciando il database soggetto al riavvio di OOM.
-
decline— Rifiuta nuove interrogazioni quando l'istanza DB ha poca memoria. kill_connect— Chiude le connessioni al database che consumano una grande quantità di memoria e termina le transazioni correnti e le istruzioni DDL (Data Definition Language). Questa risposta non è supportata per Aurora MySQL versione 2.Per ulteriori informazioni, vedere l'istruzione KILL
nella documentazione di MySQL. -
kill_query— Termina le query in ordine decrescente di consumo di memoria finché la memoria dell'istanza non supera la soglia bassa. Le istruzioni DDL non sono terminate.Per ulteriori informazioni, vedere l'istruzione KILL
nella documentazione di MySQL. -
print— Stampa solo le query che consumano una grande quantità di memoria. -
tune: ottimizza le cache delle tabelle interne per restituire un po' di memoria al sistema. Aurora MySQL riduce la memoria utilizzata per le cache, ad esempio e in condizioni di memoria insufficiente.table_open_cachetable_definition_cacheEventualmente, Aurora MySQL riporta l'utilizzo della memoria alla normalità quando il sistema non è più in condizioni di memoria insufficiente.Per ulteriori informazioni, consulta table_open_cache e table_definition_cache nella documentazione
di MySQL. tune_buffer_pool— Riduce la dimensione del buffer pool per liberare parte della memoria e renderla disponibile al server del database per l'elaborazione delle connessioni. Questa risposta è supportata per Aurora MySQL versione 3.06 e successive.È necessario eseguire l'associazione
tune_buffer_poolcon uno dei due valorikill_queryokill_connectnel valore del parametro.aurora_oom_responseIn caso contrario, il ridimensionamento del pool di buffer non avverrà, anche se si include il valore deltune_buffer_poolparametro.
Nelle versioni di Aurora MySQL precedenti alla 3.06, per le classi di istanze DB con memoria inferiore o uguale a 4 GiB, quando l'istanza è sotto pressione di memoria, le azioni predefinite includono,, e. print tune decline kill_query Per le classi di istanze DB con memoria superiore a 4 GiB, il valore del parametro è vuoto per impostazione predefinita (disabilitato).
In Aurora MySQL versione 3.06 e successive, per le classi di istanze DB con memoria inferiore o uguale a 4 GiB, Aurora MySQL chiude anche le connessioni che consumano più memoria (). kill_connect Per le classi di istanze DB con memoria superiore a 4 GiB, il valore del parametro predefinito è. print
Se si verificano spesso out-of-memory problemi, l'utilizzo della memoria può essere monitorato utilizzando tabelle di riepilogo della memoriaperformance_schema è abilitata.
