io/table/sql/handler - Amazon Aurora
Versions de moteur prises en chargeContexteCauses probables de l’augmentation du nombre d’événements d’attenteActions

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 versions 2 et 3

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 signale io/table/sql/handler, il représente le traitement InnoDB de la requête d’I/O, 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.

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.

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.

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.

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

    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 :

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 d’enregistreur et à activer l’index de hachage adaptatif.