synch/mutex/innodb/trx_sys_mutex - Amazon Aurora
Versions de moteur pertinentesContexteCauses 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.

synch/mutex/innodb/trx_sys_mutex

L'événement synch/mutex/innodb/trx_sys_mutex se produit lorsque l'activité de base de données est élevée et présente un grand nombre de transactions.

Versions de moteur pertinentes

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

En interne, le moteur de base de données InnoDB utilise le niveau d'isolement de lecture renouvelée avec instantanés pour assurer la cohérence en lecture. Vous disposez ainsi d'une vue à un instant dans le passé de la base de données lors de la création de l'instantané.

Dans InnoDB, toutes les modifications sont appliquées à la base de données dès leur arrivée, qu'elles soient validées ou non. Une telle approche signifie que sans contrôle de simultanéité multiversion (MVCC), tous les utilisateurs connectés à la base de données voient toutes les modifications et les dernières lignes. Par conséquent, InnoDB doit pouvoir suivre les modifications pour comprendre les éléments à annuler, si nécessaire.

Pour ce faire, InnoDB utilise un système de transactions (trx_sys) lui permettant de suivre les instantanés. Le système de transactions procède comme suit :

  • Il suit l'ID de transaction de chaque ligne dans les journaux d'annulation.

  • Il utilise une structure InnoDB interne appelée ReadView qui permet d'identifier les ID de transaction visibles pour un instantané.

Causes probables de l'augmentation du nombre d'événements d'attente

Toute opération de base de données nécessitant une gestion cohérente et contrôlée (création, lecture, mise à jour et suppression) des ID de transaction génère un appel entre trx_sys et le mutex.

Ces appels se produisent dans trois fonctions :

  • trx_sys_mutex_enter – Crée le mutex.

  • trx_sys_mutex_exit – Libère le mutex.

  • trx_sys_mutex_own – Teste si le mutex a un propriétaire.

L'instrumentation du schéma de performance InnoDB suit tous les appels du mutex trx_sys. Le suivi inclut, sans s'y limiter, les opérations suivantes : gestion de trx_sys 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 activité de base de données élevée avec un grand nombre de transactions entraîne l'apparition de synch/mutex/innodb/trx_sys_mutex parmi les principaux événements d'attente.

Pour plus d'informations, consultez Monitoring InnoDB Mutex Waits Using Performance Schema dans la documentation MySQL.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.

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. Voyez si vous pouvez optimiser la base de données et l'application de manière à réduire ces événements.

Pour afficher le graphique Top SQL (Principaux éléments SQL) dans la AWS Management Console

  1. Ouvrez la console Amazon RDS à 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. Sous le graphique Data load (Charge de base de données), choisissezTop 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 vue d'ensemble de la résolution des problème à l'aide de Performance Insights, consultez le billet de blogAnalyze Amazon Aurora MySQL Workloads with Performance Insights.

Examiner d'autres événements d'attente

Examinez les autres événements d'attente associés à l'événement d'attente synch/mutex/innodb/trx_sys_mutex. Ils peuvent vous fournir plus d'informations sur la nature de la charge de travail. Un grand nombre de transactions peuvent réduire le débit, mais la charge de travail peut également l'imposer.

Pour en savoir plus sur l'optimisation des transactions, consultez Optimizing InnoDB Transaction Managementdans la documentation MySQL.