io/table/sql/handler

L'événement io/table/sql/handler se produit lorsque la tâche a été déléguée à un moteur de stockage.

Versions de moteur prises en charge

Ces informations relatives aux événements d'attente sont prises en charge pour les versions de moteur suivantes :

• Aurora MySQL version 3 : 3.01.0 et 3.01.1

• Aurora MySQL version 2

Contexte

L'événement io/table indique une attente avant d'accéder à une table. Cet événement se produit indépendamment du fait que les données soient mises en cache dans le groupe de mémoires tampons ou accessibles sur disque. L'événement io/table/sql/handler indique une augmentation de l'activité de la charge de travail.

Un gestionnaire est une routine spécialisée dans un certain type de données ou axée sur certaines tâches spécifiques. Par exemple, un gestionnaire d'événements reçoit et effectue la synthèse des événements et des signaux issus du système d'exploitation ou d'une interface utilisateur. Un gestionnaire de mémoire effectue des tâches liées à la mémoire. Un gestionnaire d'entrée de fichier est une fonction qui reçoit l'entrée de fichier et effectue des tâches spécifiques sur les données, en fonction du contexte.

Des vues telles que performance_schema.events_waits_current indiquent souvent io/table/sql/handler lorsque l'attente réelle est un événement d'attente imbriqué tel qu'un verrou. Lorsque l'attente réelle n'est pas io/table/sql/handler, Performance Insights signale l'événement d'attente imbriqué. Lorsque Performance Insights publie un rapportio/table/sql/handler, cela représente le traitement de la demande d'E/S par InnoDB et non un événement d'attente imbriqué masqué. Pour plus d'informations, consultez Performance Schema Atom and Molecule Events dans le Manuel de référence MySQL.

Note

Toutefois, dans Aurora MySQL versions 3.01.0 et 3.01.1, synch/mutex/innodb/aurora_lock_thread_slot_futex est indiqué comme io/table/sql/handler.

L'événement io/table/sql/handler apparaît souvent dans les principaux événements d'attente avec des attentes I/O telles que io/aurora_redo_log_flush et io/file/innodb/innodb_data_file.

Causes probables de l'augmentation du nombre d'événements d'attente

Dans Performance Insights, des pics soudains de l'événement io/table/sql/handler indiquent une augmentation de l'activité de la charge de travail. Une activité accrue traduit une augmentation des I/O.

Performance Insights filtre les ID d'événements imbriqués et ne signale pas d'attente io/table/sql/handler lorsque l'événement imbriqué sous-jacent correspond à une attente de verrouillage. Par exemple, si l'événement de cause racine est synch/mutex/innodb/aurora_lock_thread_slot_futex, Performance Insights affiche cette attente dans les principaux événements d'attente, et non io/table/sql/handler.

Dans des vues telles que performance_schema.events_waits_current, les attentes pour io/table/sql/handler apparaissent souvent lorsque l'attente réelle est un événement d'attente imbriqué tel qu'un verrou. Lorsque l'attente réelle diffère de io/table/sql/handler, Performance Insights recherche l'attente imbriquée et signale l'attente réelle plutôt que io/table/sql/handler. Lorsque Performance Insights signale io/table/sql/handler, l'attente réelle est io/table/sql/handler, et non un événement d'attente imbriqué masqué. Pour plus d'informations, consultez Performance Schema Atom and Molecule Events dans le Manuel de référence MySQL 5.7.

Note

Toutefois, dans Aurora MySQL versions 3.01.0 et 3.01.1, synch/mutex/innodb/aurora_lock_thread_slot_futex est indiqué comme io/table/sql/handler.

Actions

Si cet événement d'attente domine l'activité de la base de données, cela n'indique pas nécessairement un problème de performances. Un événement d'attente est toujours en tête lorsque la base de données est active. Vous ne devez intervenir qu'en cas de dégradation des performances.

Nous recommandons différentes actions en fonction des autres événement d'attente que vous voyez.

Rubriques

• Identifier les sessions et les requêtes à l'origine des événements
• Vérifier une éventuelle corrélation avec les métriques de compteur Performance Insights
• Rechercher d'autres événements d'attente corrélés

Identifier les sessions et les requêtes à l'origine des événements

En règle générale, les bases de données à charge modérée à importante présentent des événements d'attente. Les événements d'attente peuvent être acceptables si les performances sont optimales. Si les performances ne sont pas optimales, voyez où la base de données passe le plus de temps. Examinez les événements d'attente qui contribuent à la charge la plus élevée et voyez si vous pouvez optimiser la base de données et l'application afin de réduire ces événements.

Pour rechercher les requêtes SQL responsables d'une charge élevée

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

2. Dans le volet de navigation, choisissez Performance Insights.

3. Choisissez une instance de base de données. Le tableau de bord Performance Insights s'affiche pour cette instance de base de données.

4. Dans le graphique Database load (Charge de base de données), choisissez Slice by wait (Tranche par attente).

5. Au bas de la page, choisissez Top SQL (Principaux éléments SQL).

   Le graphique répertorie les requêtes SQL responsables de la charge. Les requêtes situées en haut de la liste sont les plus responsables. Pour résoudre un goulet d'étranglement, concentrez-vous sur ces instructions.

Pour une présentation de la résolution des problèmes à l'aide de Performance Insights, consultez le billet de blog Analyze Amazon Aurora MySQL Workloads with Performance Insights.

Vérifier une éventuelle corrélation avec les métriques de compteur Performance Insights

Vérifiez les métriques de compteur Performance Insights telles que Innodb_rows_changed. Si les métriques de compteur sont corrélées avec io/table/sql/handler, procédez comme suit :

1. Dans Performance Insights, recherchez les instructions SQL prenant en compte le principal événement d'attente io/table/sql/handler. Si possible, optimisez cette instruction de manière à ce qu'elle renvoie moins de lignes.

2. Récupérez les tables principales des vues schema_table_statistics et x$schema_table_statistics. Ces vues indiquent le temps passé par table. Pour plus d'informations, consultez The schema_table_statistics and x$schema_table_statistics Views dans le Manuel de référence MySQL.

   Par défaut, les lignes sont triées en fonction du temps d'attente total décroissant. Les tables présentant le plus de contention apparaissent en premier. La sortie indique si le temps concerne des lectures, écritures, extractions, insertions, mises à jour ou suppressions. L'exemple suivant a été exécuté sur une instance 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)

Rechercher d'autres événements d'attente corrélés

Si synch/sxlock/innodb/btr_search_latch et io/table/sql/handler contribuent le plus à l'anomalie de charge de base de données, vérifiez si la variable innodb_adaptive_hash_index est activée. Si tel est le cas, pensez à augmenter la valeur du paramètre innodb_adaptive_hash_index_parts.

Si l'index de hachage adaptatif est désactivé, pensez à l'activer. Pour en savoir plus sur l'index de hachage adaptatif MySQL, consultez les ressources suivantes :

• Article Is Adaptive Hash Index in InnoDB right for my workload? sur le site Percona

• Adaptive Hash Index dans leManuel de référence MySQL

• Article Contention in MySQL InnoDB: Useful Info From the Semaphores Section sur le site Percona

Note

L'index de hachage adaptatif n'est pas pris en charge par les instances de base de données du lecteur Aurora.

Dans certains cas, les performances peuvent être médiocres sur une instance en lecture lorsque synch/sxlock/innodb/btr_search_latch et io/table/sql/handler sont dominants. Si tel est le cas, pensez à rediriger temporairement la charge de travail vers l'instance de base de données en écriture et à activer l'index de hachage adaptatif.