synch/mutex/innodb/trx_sys_mutex - Amazon Aurora
Versions de moteur pertinentesContexteCauses probables de l'allongement des temps 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 My SQL 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. Cela vous donne une point-in-time vue de la base de données au moment 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. Cette 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.

  • Utilise une structure InnoDB interne appelée ReadView qui permet d'identifier les transactions IDs visibles pour un instantané.

Causes probables de l'allongement des temps d'attente

Toute opération de base de données qui nécessite une gestion cohérente et contrôlée (création, lecture, mise à jour et suppression) des transactions IDs génère un appel depuis trx_sys 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 la section Surveillance des attentes d'InnoDB Mutex à l'aide du schéma de performance dans la section Ma documentation. SQL

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 SQL graphique supérieur dans le AWS Management Console

  1. Ouvrez la RDS console Amazon à 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. Dans le graphique de charge de la base de données, sélectionnez Top SQL.

    Le graphique répertorie les SQL requêtes responsables du chargement. 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.

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 plus d'informations sur la manière d'optimiser les transactions, voir Optimisation de la gestion des transactions d'InnoDB dans la section Ma SQL documentation.