Eventi di attesa Aurora MySQL

Di seguito sono riportati alcuni tra gli eventi di attesa più frequenti di Aurora MySQL.

Nota

Per informazioni sull'ottimizzazione delle prestazioni di Aurora MySQL utilizzando gli eventi di attesa, consulta Regolazione di Aurora MySQL con eventi di attesa.

Per informazioni sulle convenzioni di denominazione utilizzate per gli eventi di attesa MySQL, consulta la pagina relativa alle convenzioni di denominazione per la strumentazione dello schema di prestazioni nella documentazione di MySQL.

cpu

Il numero di connessioni attive pronte per l'esecuzione è costantemente superiore al numero di vCPUs. Per ulteriori informazioni, consulta cpu.

io/aurora_redo_log_flush

Una sessione sta mantenendo i dati permanenti nell'archiviazione Aurora. In genere, questo evento di attesa è per un'operazione di I/O di scrittura in Aurora MySQL. Per ulteriori informazioni, consulta io/aurora_redo_log_flush.

io/aurora_respond_to_client

L'elaborazione delle query è stata completata e i risultati vengono restituiti al client dell'applicazione per le seguenti versioni Aurora MySQL: 2.10.2 e versioni 2.10 successive, 2.09.3 e versioni 2.09 successive, 2.07.7 e versioni 2.07 successive. Confrontare la larghezza di banda di rete della classe di istanza database con la dimensione del set di risultati restituito. Inoltre, controlla i tempi di risposta lato client. Se il client non risponde e non è in grado di elaborare i pacchetti TCP, possono verificarsi perdite di pacchetti e ritrasmissioni TCP. Questa situazione influisce negativamente sulla larghezza di banda della rete. Nelle versioni inferiori a 2.10.2, 2.09.3 e 2.07.7, l'evento di attesa include erroneamente il tempo di inattività. Per informazioni su come ottimizzare il database quando questa attesa è importante, vedere io/aurora_respond_to_client.

io/file/csv/data

Dei thread scrivono su tabelle in formato CSV (Comma-Separated Value, valori separati da virgola). Controlla l'utilizzo delle tabelle CSV. Una causa tipica di questo evento è l'impostazione log_output in una tabella.

io/file/sql/binlog

Un thread è in attesa di un file di log binario (binlog) scritto su disco.

io/redo_log_flush

Una sessione sta mantenendo i dati permanenti nell'archiviazione Aurora. In genere, questo evento di attesa è per un'operazione di I/O di scrittura in Aurora MySQL. Per ulteriori informazioni, consulta io/redo_log_flush.

io/socket/sql/client_connection

Il programma mysqld è impegnato a creare thread per gestire le nuove connessioni client in arrivo. Per ulteriori informazioni, consulta io/socket/sql/client_connection.

io/table/sql/handler

Il motore è in attesa di accedere a una tabella. Questo evento si verifica indipendentemente dal fatto che i dati siano memorizzati nella cache nel buffer pool o se si accede su disco. Per ulteriori informazioni, consulta io/table/sql/handler.

lock/table/sql/handler

Questo evento di attesa è un gestore eventi di attesa di blocco di tabella. Per ulteriori informazioni sugli eventi "atom" e "molecule" nello schema di prestazioni, consulta eventi Atom e Molecule dello schema di prestazioni nella documentazione di MySQL.

synch/cond/innodb/row_lock_wait

Le istruzioni DML (Data Manipulation Language) accedono contemporaneamente alle stesse righe del database. Per ulteriori informazioni, consulta synch/cond/innodb/row_lock_wait.

synch/cond/innodb/row_lock_wait_cond

Più istruzioni DML (Data Manipulation Language) accedono contemporaneamente alle stesse righe del database. Per ulteriori informazioni, consulta synch/cond/innodb/row_lock_wait_cond.

synch/cond/sql/MDL_context::COND_wait_status

I thread sono in attesa di un blocco dei metadati di tabella. Il motore utilizza questo tipo di blocco per gestire l'accesso simultaneo a uno schema di database e garantire la coerenza dei dati. Per ulteriori informazioni, consulta la pagina relativa all'ottimizzazione delle operazioni di blocco nella documentazione di MySQL. Per informazioni su come ottimizzare il database quando questo evento è importante, vedere synch/cond/sql/MDL_context::COND_wait_status.

synch/cond/sql/MYSQL_BIN_LOG::COND_done

Hai attivato la registrazione binaria. Potrebbe esserci un' elevata velocità effettiva di esecuzione del commit, un numero elevato di transazioni o repliche che leggono i binlog. Prendi in considerazione l'utilizzo di istruzioni multiriga o di crezione di bundle di istruzioni in un'unica transazione. In Aurora, usa i database globali anziché la replica del log binario oppure usa i parametri aurora_binlog_*.

synch/mutex/innodb/aurora_lock_thread_slot_futex

Più istruzioni DML (Data Manipulation Language) accedono contemporaneamente alle stesse righe del database. Per ulteriori informazioni, consulta synch/mutex/innodb/aurora_lock_thread_slot_futex.

synch/mutex/innodb/buf_pool_mutex

Il pool di buffer non è abbastanza grande da contenere il set di dati funzionante. Oppure il carico di lavoro accede alle pagine da una tabella specifica, che porta a contendenze nel buffer pool. Per ulteriori informazioni, consulta synch/mutex/innodb/buf_pool_mutex.

synch/mutex/innodb/fil_system_mutex

Il processo è in attesa di accedere alla cache di memoria tablespace. Per ulteriori informazioni, consulta synch/mutex/innodb/fil_system_mutex.

synch/mutex/innodb/trx_sys_mutex

Le operazioni controllano, aggiornano, eliminano o aggiungono ID di transazione in InnoDB in modo coerente o controllato. Queste operazioni richiedono una chiamata mutex trx_sys, che viene tracciata dalla strumentazione Performance Schema. Le operazioni includono la gestione del sistema di transazioni all'avvio o all'arresto del database, i rollback, le operazioni di cancellazione degli annullamenti, l'accesso in lettura delle righe e i carichi del pool di buffer. L'elevato carico del database con un numero elevato di transazioni comporta la frequente comparsa di questo evento di attesa. Per ulteriori informazioni, consulta synch/mutex/innodb/trx_sys_mutex.

Synch/mutex/mysys/key_cache:: cache_lock

La mutex keycache->cache_lock controlla l'accesso alla cache delle chiavi per le tabelle myISAM. Sebbene Aurora MySQL non consenta l'utilizzo di tabelle MyISAM per archiviare dati persistenti, vengono utilizzate per archiviare tabelle temporanee interne. Valuta se controllare i conteggi dello stato created_tmp_disk_tables o created_tmp_tables, perché in determinate situazioni, le tabelle temporanee vengono scritte su disco quando non possono più essere contenute nella memoria.

synch/mutex/sql/file_as_table:: LOCK_offsets

Il motore acquisisce questo mutex durante l'apertura o la creazione di un file di metadati di tabella. Quando questo evento di attesa si verifica con frequenza eccessiva, il numero di tabelle create o aperte è aumentato.

synch/mutex/sql/file_as_table:: LOCK_shim_lists

Il motore acquisisce questo mutex durante l'esecuzione di operazioni come reset_size,detach_contents, oppure add_contents sulla struttura interna che tiene traccia delle tabelle aperte. Il mutex sincronizza l'accesso al contenuto dell'elenco. Quando questo evento di attesa si verifica con alta frequenza, indica un cambiamento improvviso nel set di tabelle a cui si accedeva in precedenza. Il motore deve accedere a nuove tabelle o lasciare andare il contesto relativo alle tabelle precedentemente accessibili.

synch/mutex/sql/LOCK_open

Il numero di tabelle aperte dalle sessioni supera la dimensione della cache delle definizioni di tabella o della cache aperta della tabella. Aumenta le dimensioni di queste cache. Per ulteriori informazioni, consulta la pagina relativa ad apertura e chiusura delle tabelle in MySQL.

synch/mutex/sql/LOCK_table_cache

Il numero di tabelle aperte dalle sessioni supera la dimensione della cache delle definizioni di tabella o della cache aperta della tabella. Aumenta le dimensioni di queste cache. Per ulteriori informazioni, consulta la pagina relativa ad apertura e chiusura delle tabelle in MySQL.

synch/mutex/sql/LOG

In questo evento di attesa, ci sono thread in attesa di un blocco di log. Ad esempio, un thread potrebbe attendere un blocco per scrivere nel file di log delle query con tempi di risposta molto lunghi.

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit

In questo evento di attesa, c'è un thread in attesa di acquisire un blocco per eseguire il commit nel log binario. Può verificarsi un conflitto della registrazione binaria nei database con frequenza di modifica molto alta. A seconda della versione di MySQL, vengono usati alcuni blocchi per proteggere la coerenza e la durabilità del log binario. In RDS for MySQL i log binari vengono usati per la replica e il processo di backup automatico. In Aurora MySQL i log binari non sono necessari per la replica nativa o i backup. Sono disabilitati per impostazione predefinita, ma possono essere abilitati e usati per la replica esterna o l'acquisizione dei dati delle modifiche. Per ulteriori informazioni, consulta la pagina relativa al log binario nella documentazione di MySQL.

sync/mutex/sql/MYSQL_BIN_LOG:: LOCK_dump_thread_metrics_collection

Se la registrazione binaria è attivata, il motore acquisisce questo mutex quando stampa le metriche dei thread di dump attivi nel registro degli errori del motore e sulla mappa delle operazioni interne.

sync/mutex/sql/MYSQL_BIN_LOG:: LOCK_inactive_BINlogs_map

Se la registrazione binaria è attivata, il motore acquisisce questo mutex quando aggiunge, elimina o cerca l'elenco dei file binlog dietro l'ultimo.

sync/mutex/sql/MYSQL_BIN_LOG:: LOCK_IO_cache

Se la registrazione binaria è attivata, il motore acquisisce questo mutex durante le operazioni della cache I/O di Aurora binlog: allocazione, ridimensionamento, liberazione, scrittura, lettura, rimozione e accesso alle informazioni della cache. Se questo evento si verifica frequentemente, il motore accede alla cache in cui sono memorizzati gli eventi binlog. Per ridurre i tempi di attesa, riduci i commit. Prova a raggruppare più istruzioni in una singola transazione.

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

Hai attivato la registrazione binaria. Potrebbe esserci un'elevata velocità effettiva di esecuzione del commit, molte transazioni nell'esecuzione del commit o repliche che leggono i binlog. Prendi in considerazione l'utilizzo di istruzioni multiriga o di crezione di bundle di istruzioni in un'unica transazione. In Aurora, usa i database globali anziché la replica dei log binari o usa i parametri aurora_binlog_*.

synch/mutex/sql/server_thread:: LOCK_sync

Il SERVER_THREAD::LOCK_sync mutex viene acquisito durante la pianificazione, l'elaborazione o l'avvio di thread per la scrittura di file. L'eccessiva occorrenza di questo evento di attesa indica una maggiore attività di scrittura nel database.

synch/mutex/sql/tablespace: lock

Il motore acquisisce il mutex TABLESPACES:lock durante le seguenti operazioni di tablespace: creare, eliminare, troncare ed estendere. L'eccessiva occorrenza di questo evento di attesa indica un'alta frequenza di operazioni di tablespace. Un esempio è il caricamento di una grande quantità di dati nel database.

synch/rwlock/innodb/dict

In questo evento di attesa, ci sono thread in attesa di un oggetto rwlock nel dizionario dei dati InnoDB.

synch/rwlock/innodb/dict_operation_lock

In questo evento di attesa, ci sono thread che mantengono blocchi sulle operazioni del dizionario dei dati InnoDB.

synch/rwlock/innodb/dict sys RW lock

Vengono attivati contemporaneamente un numero elevato di DCLs (Concurrent Data Control Language Statements) nel codice DDL (Data Definition Language Code). Riduci la dipendenza dell'applicazione dai DDL durante la regolare attività dell'applicazione.

synch/rwlock/innodb/index_tree_rw_lock

Un gran numero di istruzioni DML (Data Manipolation Language) simili stanno accedendo allo stesso oggetto di database contemporaneamente. Prova a usare istruzioni multiriga. Inoltre, distribuisci il carico di lavoro su diversi oggetti di database. Ad esempio, implementa il partizionamento.

synch/rwlock/innodb/dict_operation_lock

Vengono attivati contemporaneamente un numero elevato di DCLs (Concurrent Data Control Language Statements) nel codice DDL (Data Definition Language Code). Riduci la dipendenza dell'applicazione dai DDL durante la regolare attività dell'applicazione.

synch/sxlock/innodb/dict_sys_lock

Vengono attivati contemporaneamente un numero elevato di DCLs (Concurrent Data Control Language Statements) nel codice DDL (Data Definition Language Code). Riduci la dipendenza dell'applicazione dai DDL durante la regolare attività dell'applicazione.

synch/sxlock/innodb/hash_table_locks

La sessione non è in grado di trovare pagine nel pool di buffer. Il motore deve leggere un file o modificare l'elenco LRU (LRU) utilizzato meno di recente per il buffer pool. Considera di aumentare le dimensioni della cache del buffer e migliorare i percorsi di accesso per le query pertinenti.

synch/sxlock/innodb/index_tree_rw_lock

Molte istruzioni DML (Data Manipulation Language) simili accedono allo stesso oggetto di database contemporaneamente. Prova a usare istruzioni multiriga. Inoltre, distribuisci il carico di lavoro su diversi oggetti di database. Ad esempio, implementa il partizionamento.

Per ulteriori informazioni sulla risoluzione dei problemi di sincronizzazione degli eventi di attesa, consulta la sezione relativa al motivo per cui un'istanza database MySQL mostra un numero elevato di sessioni attive in attesa di eventi di attesa SYNCH in Approfondimenti sulle prestazioni.