Événements d'attente Aurora MySQL

Voici quelques événements d'attente courants pour Aurora MySQL.

Note

Pour plus d'informations sur le réglage des performances d'Aurora MySQL à l'aide d'événements d'attente, consultez Réglage d'Aurora MySQL avec des événements d'attente.

Pour de plus amples informations sur les conventions de dénomination utilisées dans les événements d'attente MySQL, veuillez consulter Performance Schema Instrument Naming Conventions dans la documentation MySQL.

cpu

Le nombre de connexions actives prêtes à être exécutées est systématiquement supérieur au nombre de vCPU. Pour plus d'informations, consultez cpu.

io/aurora_redo_log_flush

Une session conserve les données dans le stockage Aurora. Cet événement d'attente correspond généralement à une opération I/O d'écriture dans Aurora MySQL. Pour plus d'informations, consultez io/aurora_redo_log_flush.

io/aurora_respond_to_client

Le traitement des requêtes est terminé et les résultats sont renvoyés au client d'application pour les versions suivantes d'Aurora MySQL : 2.10.2 et versions 2.10 ultérieures, 2.09.3 et versions 2.09 ultérieures, 2.07.7 et versions 2.07 ultérieures. Comparez la bande passante réseau de la classe d'instance de base de données avec la taille de l'ensemble de résultats renvoyé. Vérifiez également les temps de réponse côté client. Si le client ne répond pas et n'est pas en mesure de traiter les paquets TCP, des pertes de paquets et des retransmissions TCP peuvent se produire. Cette situation affecte négativement la bande passante réseau. Dans les versions antérieures aux versions 2.10.2, 2.09.3 et 2.07.7, l'événement d'attente inclut par erreur le temps d'inactivité. Pour savoir comment régler votre base de données lorsque cette attente est importante, consultez io/aurora_respond_to_client.

io/file/csv/data

Les threads écrivent dans les tables au format CSV. Vérifiez votre utilisation de la table CSV. Cet événement est souvent déclenché par la définition de log_output sur une table.

io/file/sql/binlog

Un thread attend un fichier journal binaire (binlog) en cours d'écriture sur le disque.

io/redo_log_flush

Une session conserve les données dans le stockage Aurora. Cet événement d'attente correspond généralement à une opération I/O d'écriture dans Aurora MySQL. Pour plus d'informations, consultez io/redo_log_flush.

io/socket/sql/client_connection

Le programme mysqld est occupé à créer des threads pour gérer les nouvelles connexions client entrantes. Pour plus d'informations, consultez io/socket/sql/client_connection.

io/table/sql/handler

Le moteur attend 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. Pour plus d'informations, consultez io/table/sql/handler.

lock/table/sql/handler

Cet événement d'attente est un gestionnaire d'événements d'attente de verrouillage de table. Pour de plus amples informations sur les événements « atom » et « molecule » du schéma de performance, consultez Performance Schema atom and molecule events dans la documentation MySQL.

synch/cond/innodb/row_lock_wait

Plusieurs instructions en langage de manipulation de données (DML) accèdent simultanément aux mêmes lignes de base de données. Pour plus d'informations, consultez synch/cond/innodb/row_lock_wait.

synch/cond/innodb/row_lock_wait_cond

Plusieurs instructions DML accèdent simultanément aux mêmes lignes de base de données. Pour plus d'informations, consultez synch/cond/innodb/row_lock_wait_cond.

synch/cond/sql/MDL_context::COND_wait_status

Les threads attendent sur un verrou de métadonnées de table. Le moteur utilise ce type de verrou pour gérer l'accès simultané à un schéma de base de données et assurer la cohérence des données. Pour de plus amples informations, veuillez consulter Optimizing Locking Operations dans la documentation MySQL. Pour savoir comment régler votre base de données lorsque cet événement est important, consultez synch/cond/sql/MDL_context::COND_wait_status.

synch/cond/sql/MYSQL_BIN_LOG::COND_done

Vous avez activé la journalisation binaire. Il peut y avoir un débit de validation élevé, un grand nombre de transactions en cours de validation ou des réplicas lisant des journaux binaires. Envisagez d'utiliser des instructions à plusieurs lignes ou de regrouper des instructions dans une seule transaction. Dans Aurora, privilégiez les bases de données globales à la réplication des journaux binaires, ou utilisez le paramètres aurora_binlog_*.

synch/mutex/innodb/aurora_lock_thread_slot_futex

Plusieurs instructions DML accèdent simultanément aux mêmes lignes de base de données. Pour plus d'informations, consultez synch/mutex/innodb/aurora_lock_thread_slot_futex.

synch/mutex/innodb/buf_pool_mutex

Le groupe de mémoires de tampons n'est pas suffisamment grand pour contenir l'ensemble de données de travail. Ou bien, la charge de travail accède aux pages d'une table spécifique, ce qui entraîne une contention dans le groupe de mémoires tampons. Pour plus d'informations, consultez synch/mutex/innodb/buf_pool_mutex.

synch/mutex/innodb/fil_system_mutex

Le processus est en attente d'accès au cache mémoire de l'espace disque logique. Pour plus d'informations, consultez synch/mutex/innodb/fil_system_mutex.

synch/mutex/innodb/trx_sys_mutex

Les opérations sont la vérification, la mise à jour, la suppression ou l'ajout d'ID de transaction dans InnoDB de manière cohérente ou contrôlée. Ces opérations nécessitent un appel de mutex trx_sys, suivi par l'instrumentation Performance Schema. Parmi les opérations figurent les suivantes : gestion du système de transactions lorsque la base de données démarre ou s'arrête, restaurations, nettoyages après annulation, accès en lecture de ligne et charges de groupe de mémoires tampons. Une charge de base de données élevée avec un grand nombre de transactions entraîne l'apparition fréquente de cet événement d'attente. Pour plus d'informations, consultez synch/mutex/innodb/trx_sys_mutex.

synch/mutex/mysys/KEY_CACHE::cache_lock

Le mutex keycache->cache_lock contrôle l'accès au cache de clé pour les tables MyISAM. Bien qu'Aurora MySQL n'autorise pas l'utilisation des tables MyISAM pour stocker des données persistantes, elles sont utilisées pour stocker des tables temporaires internes de stockage. Envisagez de vérifier les compteurs d'état created_tmp_tables et created_tmp_disk_tables, car dans certaines situations, les tables temporaires sont écrites sur le disque lorsqu'elles ne tiennent plus dans la mémoire.

synch/mutex/sql/FILE_AS_TABLE::LOCK_offsets

Le moteur acquiert ce mutex lors de l'ouverture ou de la création d'un fichier de métadonnées de table. Lorsque cet événement d'attente se produit à une fréquence excessive, le nombre de tables créées ou ouvertes a connu un pic.

synch/mutex/sql/FILE_AS_TABLE::LOCK_shim_lists

Le moteur acquiert ce mutex tout en effectuant des opérations telles que reset_size, detach_contents ou add_contents sur la structure interne qui permet de suivre les tables ouvertes. Le mutex synchronise l'accès au contenu de la liste. Lorsque cet événement d'attente se produit très fréquemment, cela indique un changement soudain de l'ensemble de tables précédemment consultées. Le moteur doit accéder à de nouvelles tables ou renoncer au contexte lié aux tables précédemment consultées.

synch/mutex/sql/LOCK_open

Le nombre de tables que vos sessions ouvrent dépasse la taille du cache de définition de table ou du cache ouvert de table. Augmentez la taille de ces caches. Pour de plus amples informations, veuillez consulter How MySQL opens and closes tables.

synch/mutex/sql/LOCK_table_cache

Le nombre de tables que vos sessions ouvrent dépasse la taille du cache de définition de table ou du cache ouvert de table. Augmentez la taille de ces caches. Pour de plus amples informations, veuillez consulter How MySQL opens and closes tables.

synch/mutex/sql/LOG

Dans cet événement d'attente, certains threads attendent un verrouillage des journaux. Par exemple,un thread peut attendre qu'un verrouillage écrive dans le fichier journal de requêtes lentes.

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit

Dans cet événement d'attente, un thread attend d'acquérir un verrouillage avec l'intention de valider dans le journal binaire. Des conflits de journalisation binaire peuvent se produire sur des bases de données présentant un rythme de changement très élevé. Selon votre version de MySQL, certains verrouillages sont utilisés pour protéger la cohérence et la longévité du journal binaire. Dans RDS pour MySQL, les journaux binaires sont utilisés pour la réplication et le processus de sauvegarde automatisée. Dans Aurora MySQL, les journaux binaires ne sont pas nécessaires pour la réplication native ou les sauvegardes. Ils sont désactivés par défaut, mais ils peuvent être activés et utilisés pour la réplication externe ou la capture des données modifiées. Pour de plus amples informations, veuillez consulter The Binary Log dans la documentation MySQL.

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_dump_thread_metrics_collection

Si la journalisation binaire est activée, le moteur acquiert ce mutex lorsqu'il imprime des métriques de threads de vidage actifs dans le journal des erreurs du moteur et sur le mappage des opérations internes.

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_inactive_binlogs_map

Si la journalisation binaire est activée, le moteur acquiert ce mutex lorsqu'il ajoute, supprime ou effectue une recherche dans la liste des fichiers binlog antérieurs au plus récent.

sync/mutex/sql/MYSQL_BIN_LOG::LOCK_io_cache

Si la journalisation binaire est activée, le moteur acquiert ce mutex lors des opérations de cache d'I/O du journal binaire Aurora : allouer, redimensionner, libérer, écrire, lire, purger et accéder aux informations du cache. Si cet événement se produit fréquemment, le moteur accède au cache où les événements de journal binaire sont stockés. Pour réduire les temps d'attente, réduisez les validations. Essayez de regrouper plusieurs instructions dans une seule transaction.

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

Vous avez activé la journalisation binaire. Il peut y avoir un débit de validation élevé, de nombreuses transactions en cours de validation ou des réplicas lisant des journaux binaires. Envisagez d'utiliser des instructions à plusieurs lignes ou de regrouper des instructions dans une seule transaction. Dans Aurora, privilégiez les bases de données globales à la réplication des journaux binaires, ou utilisez le paramètres aurora_binlog_*.

synch/mutex/sql/SERVER_THREAD::LOCK_sync

Le mutex SERVER_THREAD::LOCK_sync est acquis lors de la planification, du traitement ou du lancement de threads pour les écritures de fichier. Si cet événement d'attente se produit de manière excessive, cela indique une activité d'écriture accrue dans la base de données.

synch/mutex/sql/TABLESPACES:lock

Le moteur acquiert le mutex TABLESPACES:lock lors des opérations d'espace disque logique suivantes : créer, supprimer, tronquer et étendre. Si cet événement d'attente se produit de manière excessive, cela indique une fréquence élevée d'opérations d'espace disque logique. Le chargement d'une grande quantité de données dans la base de données en est un exemple.

synch/rwlock/innodb/dict

Dans cet événement d'attente, certains threads attendent un rwlock maintenu sur le dictionnaire de données InnoDB.

synch/rwlock/innodb/dict_operation_lock

Dans cet événement d'attente, certains threads maintiennent des verrouillages sur les opérations de dictionnaire de données InnoDB.

synch/rwlock/innodb/dict sys RW lock

Un nombre élevé d'instructions en langage de contrôle des données simultanées (DCL) dans le code de langage de définition de données (DDL) sont déclenchées simultanément. Réduisez la dépendance de l'application à l'égard des DDL lors de l'activité régulière de l'application.

synch/rwlock/innodb/index_tree_rw_lock

Un grand nombre d'instructions en langage de manipulation de données (DML) accèdent simultanément au même objet de base de données. Essayez d'utiliser des instructions à plusieurs lignes. Répartissez également la charge de travail sur différents objets de base de données. Par exemple, implémentez le partitionnement.

synch/sxlock/innodb/dict_operation_lock

Un nombre élevé d'instructions en langage de contrôle des données simultanées (DCL) dans le code de langage de définition de données (DDL) sont déclenchées simultanément. Réduisez la dépendance de l'application à l'égard des DDL lors de l'activité régulière de l'application.

synch/sxlock/innodb/dict_sys_lock

Un nombre élevé d'instructions en langage de contrôle des données simultanées (DCL) dans le code de langage de définition de données (DDL) sont déclenchées simultanément. Réduisez la dépendance de l'application à l'égard des DDL lors de l'activité régulière de l'application.

synch/sxlock/innodb/hash_table_locks

La session n'a pas pu trouver de pages dans le groupe de mémoires tampons. Le moteur doit lire un fichier ou modifier la liste utilisée le moins récemment (LRU) pour le groupe de mémoires tampons. Envisagez d'augmenter la taille du cache de mémoire tampon et d'améliorer les chemins d'accès pour les requêtes pertinentes.

synch/sxlock/innodb/index_tree_rw_lock

Un grand nombre d'instructions similaires en langage de manipulation de données (DML) accèdent simultanément au même objet de base de données. Essayez d'utiliser des instructions à plusieurs lignes. Répartissez également la charge de travail sur différents objets de base de données. Par exemple, implémentez le partitionnement.

Pour plus d'informations sur le dépannage des événements d'attente SYNCH, consultez Pourquoi mon instance DB MySQL affiche-t-il un nombre élevé de séances actives en attente sur les événements d'attente SYNCH dans Performance Insights ?