Eventi Aurora My wait SQL

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

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

L'elaborazione delle query è stata completata e i risultati vengono restituiti al client dell'applicazione per le seguenti versioni di Aurora My: 2.10.2 e SQL versioni 2.10 successive, 2.09.3 e versioni 2.09 successive e 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, possono verificarsi perdite di pacchetti e ritrasmissioni. TCP 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.

I thread scrivono su tabelle nel formato value () separato da virgole. CSV Controlla l'utilizzo della tua tabella. CSV Una causa tipica di questo evento è l'impostazione log_output in una tabella.

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

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

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

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.

Questo evento di attesa è un gestore eventi di attesa di blocco di tabella. Per ulteriori informazioni sugli eventi relativi agli atomi e alle molecole nello schema delle prestazioni, vedete gli eventi relativi agli atomi e alle molecole dello schema delle prestazioni nella documentazione My. SQL

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

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

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, vedere Ottimizzazione delle operazioni di blocco nella documentazione personale. SQL Per informazioni su come ottimizzare il database quando questo evento è importante, vedere synch/cond/sql/MDL_context::COND_wait_status.

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_*.

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

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.

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

Le operazioni consistono nel controllare, aggiornare, eliminare o aggiungere transazioni IDs 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.

Il mutex controlla l'accesso alla cache delle chiavi per My tables. keycache->cache_lock ISAM Sebbene Aurora My SQL non consenta l'utilizzo di Le mie ISAM tabelle 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.

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.

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.

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, vedi How My opens and closes tables. SQL

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, vedi How My opens and close tables. SQL

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.

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 My in usoSQL, vengono utilizzati alcuni blocchi per proteggere la consistenza e la durabilità del registro binario. In RDS for MySQL, i log binari vengono utilizzati per la replica e il processo di backup automatizzato. In Aurora MySQL, i log binari non sono necessari per la replica o i backup nativi. 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 The binary log nella documentazione My. SQL

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.

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

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.

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_*.

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.

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.

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

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

Un numero elevato di istruzioni simultanee del linguaggio di controllo dei dati (DCLs) nel codice del linguaggio di definizione dei dati () vengono attivate contemporaneamente. DDLs Riduci la dipendenza dell'applicazione DDLs durante la normale attività dell'applicazione.

Un gran numero di istruzioni simili del linguaggio di manipolazione dei dati (DML) 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.

Un numero elevato di istruzioni simultanee del linguaggio di controllo dei dati (DCLs) nel linguaggio di definizione dei dati code (DDLs) viene attivato contemporaneamente. Riduci la dipendenza dell'applicazione DDLs durante la normale attività dell'applicazione.

Un numero elevato di istruzioni simultanee del linguaggio di controllo dei dati (DCLs) nel codice del linguaggio di definizione dei dati (DDLs) viene attivato contemporaneamente. Riduci la dipendenza dell'applicazione DDLs durante la normale attività dell'applicazione.

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

Molte istruzioni simili del linguaggio di manipolazione dei dati (DML) 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.