Événements relatifs à Aurora SQL My Wait

Le nombre de connexions actives prêtes à être exécutées est constamment supérieur au nombre devCPUs. Pour de plus amples informations, veuillez consulter cpu.

Une session conserve les données dans le stockage Aurora. Cet événement d'attente concerne généralement une opération d'E/S d'écriture dans Aurora MySQL. Pour de plus amples informations, veuillez consulter io/aurora_redo_log_flush.

Le traitement des requêtes est terminé et les résultats sont renvoyés au client de l'application pour les SQL versions suivantes d'Aurora My : 2.10.2 et versions 2.10 supérieures, versions 2.09.3 et supérieures 2.09, et versions 2.07.7 et supérieures 2.07. 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 ne peut pas traiter les TCP paquets, des abandons de paquets et des TCP retransmissions 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 des tables au format valeur séparée par des virgules (CSV). Vérifiez l'utilisation CSV de votre table. 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. Cet événement d'attente concerne généralement une opération d'E/S 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 liés aux atomes et aux molécules dans le schéma de performance, consultez la section Événements atomiques et moléculaires du schéma de performance dans la section Ma SQL documentation.

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

Plusieurs DML instructions accèdent aux mêmes lignes de base de données en même temps. 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 la section Optimisation des opérations de verrouillage dans la section Ma SQL documentation. 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 DML instructions accèdent aux mêmes lignes de base de données en même temps. 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 keycache->cache_lock mutex contrôle l'accès au cache de clés pour Mes ISAM tables. Bien qu'Aurora My SQL n'autorise pas l'utilisation de Mes ISAM tables pour stocker des données persistantes, elles sont utilisées pour stocker des tables temporaires internes. 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, voir Comment My SQL ouvre et ferme des 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, voir Comment My SQL ouvre et ferme des 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 verrous sont utilisés pour protéger la cohérence et la durabilité du journal binaire. Dans RDS for MySQL, les journaux binaires sont utilisés pour la réplication et le processus de sauvegarde automatique. 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 la section Le journal binaire dans la section Ma SQL documentation.

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 similaires du langage de manipulation de données (DML) accèdent au même objet de base de données en même temps. 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 soit lire un fichier, soit modifier la liste des fichiers les moins récemment utilisés (LRU) pour le pool de mémoire tampon. 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.

De nombreuses instructions similaires du langage de manipulation de données (DML) accèdent au même objet de base de données en même temps. 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.