io/table/sql/handler - Amazon Aurora
Versioni del motore supportateContextProbabili cause di aumento delle atteseAzioni

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

io/table/sql/handler

L’evento io/table/sql/handler si verifica quando il lavoro è stato delegato a un motore di archiviazione.

Versioni del motore supportate

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:

  • Aurora SQL Le mie versioni 2 e 3

Context

L'evento io/table indica un'attesa per l'accesso a una tabella. Questo evento si verifica indipendentemente dal fatto che i dati siano memorizzati nella cache nel pool di buffer o se si acceda su disco. L’evento io/table/sql/handler indica un aumento dell'attività del carico di lavoro.

Un handler è una routine specializzata in un determinato tipo di dati o incentrata su determinate attività speciali. Ad esempio, un handler di eventi riceve e digerisce eventi e segnali dal sistema operativo o da un'interfaccia utente. Un handler di memoria esegue processi relativi alla memoria. Un handler di input di file è una funzione che riceve l'input di file ed esegue attività speciali sui dati, in base al contesto.

Visualizzazioni come performance_schema.events_waits_current spesso mostrano io/table/sql/handler quando l'attesa effettiva è un evento di attesa annidato come un blocco. Quando l'attesa effettiva non è io/table/sql/handler, Approfondimenti sulle prestazioni segnala l'evento di attesa annidato. Quando Performance Insights riportaio/table/sql/handler, rappresenta l'elaborazione di InnoDB della richiesta di I/O e non un evento di attesa annidato nascosto. Per ulteriori informazioni, consulta Performance Schema Atom and Molecule Events nel My Reference Manual. SQL

L'io/table/sql/handlerevento compare spesso negli eventi di massima attesa con attese di I/O come. io/aurora_redo_log_flush

Probabili cause di aumento delle attese

In Approfondimenti sulle prestazioni, picchi improvvisi nell’evento io/table/sql/handler indicano un aumento dell'attività del carico di lavoro. Aumento dell'attività significa un aumento dell'I/O.

Performance Insights filtra l'evento di nidificazione IDs e non segnala un'io/table/sql/handlerattesa quando l'evento nidificato sottostante è un'attesa di blocco. Ad esempio, se l'evento causa principale è synch/mutex/innodb/aurora_lock_thread_slot_futex, Approfondimenti sulle prestazioni visualizza questa attesa nei primi eventi di attesa e non io/table/sql/handler.

In visualizzazioni come performance_schema.events_waits_current, le attese di io/table/sql/handler spesso appaiono quando l'attesa effettiva è un evento di attesa annidato come un blocco. Quando l'attesa effettiva è diversa da io/table/sql/handler, Approfondimenti sulle prestazioni cerca l'attesa annidata e segnala l'attesa effettiva anziché io/table/sql/handler. Quando Approfondimenti sulle prestazioni segnala io/table/sql/handler, la vera attesa è io/table/sql/handler e non un evento di attesa annidato nascosto. Per ulteriori informazioni, consulta Performance Schema Atom and Molecule Events nel manuale di riferimento My SQL 5.7.

Azioni

Se l’evento di attesa domina l'attività del database, non indica necessariamente un problema di prestazioni. Un evento di attesa è sempre in primo piano quando il database è attivo. È necessario agire solo quando le prestazioni diminuiscono.

Consigliamo azioni diverse a seconda degli altri eventi di attesa visualizzati.

Identificare le sessioni e le query che causano gli eventi

In genere, i database con carico da moderato a significativo hanno eventi di attesa. Gli eventi di attesa possono essere accettabili se le prestazioni sono ottimali. Se le prestazioni non sono ottimali, esaminare dove il database impiega più tempo. Considerare gli eventi di attesa che contribuiscono al carico più elevato per scoprire se è possibile ottimizzare il database e l'applicazione per ridurre tali eventi.

Per trovare le SQL interrogazioni responsabili di un carico elevato

  1. Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel pannello di navigazione scegli Approfondimenti sulle prestazioni.

  3. Scegli un'istanza database. Viene visualizzato il pannello di controllo di Approfondimenti sulle prestazioni per l'istanza database.

  4. Nel grafico Carico del database, scegli Dividi per attesa.

  5. Nella parte inferiore della pagina, scegli Top SQL.

    Il grafico elenca le SQL interrogazioni responsabili del carico. Quelli in cima all'elenco sono le più responsabili. Per risolvere un collo di bottiglia, occorre concentrarsi su queste istruzioni.

Per un'utile panoramica sulla risoluzione dei problemi con Performance Insights, consulta il post del blog Analizza i miei SQL carichi di lavoro di Amazon Aurora con Performance Insights.

Verifica la presenza di una correlazione con i parametri dei contatori di Approfondimenti sulle prestazioni

Verifica la presenza di parametri del contatore di Approfondimenti sulle prestazioni come Innodb_rows_changed. Se i parametri del contatore sono correlati con io/table/sql/handler, segui questi passaggi:

  1. In Performance Insights, cerca i SQL rendiconti che rappresentano l'evento di io/table/sql/handler massima attesa. Se possibile, ottimizza questa istruzione in modo che restituisca un numero inferiore di righe.

  2. Recupera le tabelle principali dalle visualizzazione schema_table_statistics e x$schema_table_statistics. Queste visualizzazioni mostrano la quantità di tempo impiegato per tabella. Per ulteriori informazioni, consulta Le viste schema_table_statistics e x$schema_table_statistics nel My Reference Manual. SQL

    Per impostazione predefinita, le righe vengono ordinate in base al tempo di attesa totale discendente. Le tabelle con il maggior numero di contese appaiono per prime. L'output indica se il tempo viene impiegato per le letture, le scritture, il recupero, gli inserimenti, gli aggiornamenti o le eliminazioni.

    mysql> select * from sys.schema_table_statistics limit 1\G

*************************** 1. row ***************************
     table_schema: read_only_db
       table_name: sbtest41
    total_latency: 54.11 m
     rows_fetched: 6001557
    fetch_latency: 39.14 m
    rows_inserted: 14833
   insert_latency: 5.78 m
     rows_updated: 30470
   update_latency: 5.39 m
     rows_deleted: 14833
   delete_latency: 3.81 m
 io_read_requests: NULL
          io_read: NULL
  io_read_latency: NULL
io_write_requests: NULL
         io_write: NULL
 io_write_latency: NULL
 io_misc_requests: NULL
  io_misc_latency: NULL
1 row in set (0.11 sec)

Verifica la presenza di altri eventi di attesa correlati

Se synch/sxlock/innodb/btr_search_latch e io/table/sql/handler insieme contribuiscono maggiormente all'anomalia del carico del database, verificare se la variabile innodb_adaptive_hash_index è attivata. Se lo è, considera la possibilità di aumentare il valore del parametro innodb_adaptive_hash_index_parts.

Se l’indice adattivo Hash è disattivato, considera la possibilità di attivarlo. Per ulteriori informazioni sul My Adaptive Hash Index, consulta le seguenti risorse: SQL

Nota

L'indice adattivo Hash non è supportato nelle istanze database di lettura di Aurora.

In alcuni casi, le prestazioni potrebbero risultare scadenti su un’istanza di lettura quando synch/sxlock/innodb/btr_search_latch e io/table/sql/handler sono dominanti. In tal caso, prendere in considerazione il reindirizzamento temporaneo del carico di lavoro all’istanza database di scrittura e l'attivazione dell’indice adattivo Hash.