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 My SQL version 3 : 3.01.0 et 3.01.1

  • Aurora Ma SQL 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 la section Événements atomiques et moléculaires du schéma de performance dans le manuel My SQL Reference.

Note

Toutefois, dans Aurora My, SQL les versions 3.01.0 et 3.01.1 synch/mutex/innodb/aurora_lock_thread_slot_futex sont signalées 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 l'événement d'imbrication IDs et ne signale pas d'io/table/sql/handlerattente lorsque l'événement imbriqué sous-jacent est une attente bloquée. 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 la section Événements atomiques et moléculaires du schéma de performance dans le manuel de référence My SQL 5.7.

Note

Toutefois, dans Aurora My, SQL les versions 3.01.0 et 3.01.1 synch/mutex/innodb/aurora_lock_thread_slot_futex sont signalées 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.

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 SQL les requêtes responsables d'une charge élevée

  1. Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à 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.

    Le graphique répertorie les SQL requêtes 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 utile du dépannage à l'aide de Performance Insights, consultez le billet de blog Analyze Amazon Aurora My SQL 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 SQL relevés comptabilisant le io/table/sql/handler plus grand événement d'attente. 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 les vues schema_table_statistics et x$schema_table_statistics dans le manuel My Reference Manual. SQL

    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 My SQL 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 My SQL Adaptive Hash, 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 en écriture et à activer l'index de hachage adaptatif.