Événements d’attente Aurora MySQL

Le nombre de connexions actives prêtes à fonctionner est constamment supérieur au nombre de CPUs v. Pour plus d'informations, consultezcpu.

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.

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.

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.

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

Une session conserve les données dans le stockage Aurora. Généralement, cet événement d'attente concerne une I/O opération d'écriture dans Aurora MySQL. Pour de plus amples informations, veuillez consulter io/redo_log_flush.

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

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 de plus amples informations, veuillez consulter io/table/sql/handler.

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

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

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

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 plus d’informations, consultez 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.

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_*.

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

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 de plus amples informations, veuillez consulter synch/mutex/innodb/buf_pool_mutex.

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

Les opérations vérifient, mettent à jour, suppriment ou ajoutent des transactions IDs 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 de plus amples informations, veuillez consulter synch/mutex/innodb/trx_sys_mutex.

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.

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.

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.

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 plus d’informations, consultez How MySQL opens and closes tables.

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 plus d’informations, consultez How MySQL opens and closes tables.

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.

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 plus d’informations, consultez The Binary Log dans la documentation MySQL.

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.

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.

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.

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_*.

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.

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.

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

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

Un grand nombre d'instructions simultanées du langage de contrôle des données (DCLs) dans le code du langage de définition des données (DDLs) sont déclenchées simultanément. Réduisez la dépendance de l'application par rapport à DDLs l'activité normale de l'application.

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.

Un grand nombre d'instructions simultanées du langage de contrôle des données (DCLs) dans le code du langage de définition des données (DDLs) sont déclenchées simultanément. Réduisez la dépendance de l'application par rapport à DDLs l'activité normale de l'application.

Un grand nombre d'instructions simultanées du langage de contrôle des données (DCLs) dans le code du langage de définition des données (DDLs) sont déclenchées simultanément. Réduisez la dépendance de l'application par rapport à DDLs l'activité normale de l'application.

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.

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.

Cet événement d'attente se produit lorsqu'une session attend d'acquérir un mutex pour gérer le pool de tablespaces temporaires de session.