io/table/sql/handler

El evento io/table/sql/handler se produce cuando el trabajo se ha delegado en un motor de almacenamiento.

Versiones del motor admitidas

Esta información de evento de espera es compatible con las siguientes versiones del motor:

• Aurora MySQL versión 3: 3.01.0 y 3.01.1

• Aurora MySQL versión 2

Context

El evento io/table indica una espera para acceder a una tabla. Este evento se produce independientemente de si los datos se almacenan en caché en el grupo de búferes o si se accede en el disco. El evento io/table/sql/handler indica un aumento de la actividad de la carga de trabajo.

Un controlador es una rutina especializada en un determinado tipo de datos o centrada en determinadas tareas especiales. Por ejemplo, un controlador de eventos recibe y procesa eventos y señales del sistema operativo o de una interfaz de usuario. Un controlador de memoria realiza tareas relacionadas con la memoria. Un controlador de entrada de archivos es una función que recibe una entrada de archivos y realiza tareas especiales en los datos, en función del contexto.

Vistas como, por ejemplo, performance_schema.events_waits_current, a menudo muestran io/table/sql/handler cuando la espera real es un evento de espera anidado como un bloqueo. Cuando la espera real no es io/table/sql/handler, Información sobre rendimiento informa del evento de espera anidado. Cuando Información sobre rendimiento informa io/table/sql/handler, representa el procesamiento de la solicitud de E/S por parte de InnoDB y no un evento de espera anidado oculto. Para obtener más información, consulte Performance Schema Atom and Molecule Events en MySQL Reference Manual.

nota

Sin embargo, en las versiones 3.01.0 y 3.01.1 de Aurora MySQL, synch/mutex/innodb/aurora_lock_thread_slot_futex se indica como io/table/sql/handler.

El evento io/table/sql/handler a menudo aparece en los principales eventos de espera con esperas de E/S como io/aurora_redo_log_flush y io/file/innodb/innodb_data_file.

Causas probables del aumento de las esperas

En Información sobre rendimiento, los picos repentinos en el evento io/table/sql/handler indican un aumento de la actividad de la carga de trabajo. El aumento de la actividad significa un aumento de E/S.

Información sobre rendimiento filtra los ID de eventos de anidamiento y no informa de ninguna espera de io/table/sql/handler cuando el evento anidado subyacente sea una espera de bloqueo. Por ejemplo, si el evento de causa raíz es synch/mutex/innodb/aurora_lock_thread_slot_futex, Información sobre rendimiento muestra esta espera en los eventos de espera principales y no io/table/sql/handler.

En vistas como, por ejemplo, performance_schema.events_waits_current, las esperas de io/table/sql/handler a menudo aparecen cuando la espera real es un evento de espera anidado como un bloqueo. Cuando la espera real difiere de io/table/sql/handler, Información sobre rendimiento busca la espera anidada e informa de la espera real en lugar de io/table/sql/handler. Cuando Información sobre rendimiento informa de io/table/sql/handler, la espera real es io/table/sql/handler y no un evento de espera anidado oculto. Para obtener más información, consulte Performance Schema Atom and Molecule Events en MySQL 5.7 Reference Manual.

nota

Sin embargo, en las versiones 3.01.0 y 3.01.1 de Aurora MySQL, synch/mutex/innodb/aurora_lock_thread_slot_futex se indica como io/table/sql/handler.

Acciones

Si este evento de espera domina la actividad de la base de datos, no indica necesariamente un problema de rendimiento. Cuando la base de datos está activa, siempre hay un evento de espera activo. Solo debe actuar cuando el rendimiento se vea reducido.

Recomendamos diferentes acciones en función de los demás eventos de espera que vea.

Temas

• Identificar las sesiones y consultas que provocan los eventos
• Verificar la correlación con las métricas de contador de Información sobre rendimiento
• Verificar otros eventos de espera correlacionados

Identificar las sesiones y consultas que provocan los eventos

Normalmente, las bases de datos con una carga de moderada a significativa tienen eventos de espera. Los eventos de espera pueden ser aceptables si el rendimiento es óptimo. Si el rendimiento no es óptimo, examine dónde pasa más tiempo la base de datos. Preste atención a los eventos de espera que contribuyen a la carga más alta y averigüe si puede optimizar la base de datos y la aplicación para reducirlos.

Para buscar consultas SQL responsables de cargas elevadas

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. En el panel de navegación, seleccione Información sobre rendimiento.

3. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.

4. En el cuadro Database load (Carga de base de datos), elija Slice by wait (Corte por espera).

5. En la parte inferior de la página, elija Top SQL (SQL principal).

   El gráfico enumera las consultas SQL responsables de la carga. Las que están en la parte superior de la lista son las más importantes. Para resolver un cuello de botella, céntrese en estas instrucciones.

Para obtener información general útil sobre la solución de problemas mediante Información sobre rendimiento, consulte la entrada de blog Analyze Amazon Aurora MySQL Workloads with Performance Insights.

Verificar la correlación con las métricas de contador de Información sobre rendimiento

Verifique si hay métricas de contador de Información sobre rendimiento como Innodb_rows_changed. Si las métricas de contador están correlacionadas con io/table/sql/handler, siga los pasos que se indican a continuación:

1. En Información sobre rendimiento, busque las instrucciones SQL responsables del evento de espera principal io/table/sql/handler. Si es posible, optimice esta instrucción para que devuelva menos filas.

2. Recupere las tablas principales de las vistas schema_table_statistics y x$schema_table_statistics. Estas vistas muestran la cantidad de tiempo que empleó la tabla. Para obtener más información, consulte The schema_table_statistics and x$schema_table_statistics Views en el MySQL Reference Manual.

   De forma predeterminada, las filas se ordenan por tiempo de espera total descendente. Las tablas con más contención se muestran en primer lugar. La salida indica si el tiempo se dedica a lecturas, escrituras, recuperaciones, inserciones, actualizaciones o eliminaciones. El siguiente ejemplo se ejecutó en una instancia de 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)

Verificar otros eventos de espera correlacionados

Si synch/sxlock/innodb/btr_search_latch y io/table/sql/handler contribuyen más a la anomalía de carga de la base de datos, verifique si la variable innodb_adaptive_hash_index está activada. Si lo está, considere la posibilidad de aumentar el valor del parámetro innodb_adaptive_hash_index_parts.

Si el índice hash adaptativo está desactivado, considere la posibilidad de activarlo. Para obtener más información acerca del índice hash adaptativo, consulte los siguientes recursos:

• Artículo Is Adaptive Hash Index in InnoDB right for my workload? en el sitio web de Percona.

• Adaptive Hash Index en el MySQL Reference Manual.

• Artículo Contention in MySQL InnoDB: Useful Info From the Semaphores Section en el sitio web de Percona.

nota

El índice hash adaptativo no se admite en instancias de base de datos de lector de Aurora.

En algunos casos, el rendimiento puede ser deficiente en una instancia lectora cuando synch/sxlock/innodb/btr_search_latch y io/table/sql/handler son dominantes. Si es así, considere la posibilidad de redirigir la carga de trabajo temporalmente a la instancia de base de datos del escritor y active el índice hash adaptativo.