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 MySQL versione 3: 3.01.0 e 3.01.1

• Aurora MySQL versione 2

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 Manuale di riferimento di MySQL.

Nota

Tuttavia, in Aurora MySQL versione 3.01.0 e 3.01.1, synch/mutex/innodb/aurora_lock_thread_slot_futex è indicato come io/table/sql/handler.

L’evento io/table/sql/handler appare spesso negli eventi di attesa principali con attese I/O come io/aurora_redo_log_flush e io/file/innodb/innodb_data_file.

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.

Approfondimenti sulle prestazioni filtra gli ID degli eventi di nidificazione e non segnala un evento di attesa io/table/sql/handler quando l'evento annidato 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 di MySQL 5.7.

Nota

Tuttavia, in Aurora MySQL versione 3.01.0 e 3.01.1, synch/mutex/innodb/aurora_lock_thread_slot_futex è indicato come io/table/sql/handler.

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.

Argomenti

• Identificare le sessioni e le query che causano gli eventi
• Verifica la presenza di una correlazione con i parametri dei contatori di Approfondimenti sulle prestazioni
• Verifica la presenza di altri eventi di attesa correlati

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 query di SQL responsabili del carico elevato

1. Accedi alla AWS Management Console e apri la console Amazon RDS 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 Prime Instruzioni SQL.

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

Per una panoramica utile dell’identificazione e della risoluzione dei problemi con Approfondimenti sulle prestazioni, consulta il post del blogAnalizza i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni.

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 Approfondimenti sulle prestazioni, cerca le istruzioni SQL che rappresentano l’evento di attesa principale io/table/sql/handler. 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 visualizzazioni schema_table_statistics e x$schema_table_statistics nel Manuale di riferimento di MySQL.

   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. L'esempio seguente è stato eseguito su un'istanza di Aurora MySQL 2.09.1.

   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 sull’indice adattivo Hash di MySQL, consulta le seguenti risorse:

• L'articolo L’indice adattivo Hash in InnoDB è adatto al mio carico di lavoro? sul sito web di Percona

• Indice adattivo Hash nel Manuale di riferimento di MySQL

• L'articolo Contesa in MySQL InnoDB: informazioni utili dalla sezione Segnalazioni sul sito web di Percona

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.