synch/mutex/innodb/buf_pool_mutex

L'événement synch/mutex/innodb/buf_pool_mutex se produit lorsqu'un thread a acquis un verrouillage sur le groupe de mémoires tampons InnoDB afin d'accéder à une page en mémoire.

Versions de moteur pertinentes

Ces informations relatives aux événements d'attente sont prises en charge pour les versions de moteur suivantes :

• Aurora MySQL version 2

Contexte

Le mutex buf_pool est un mutex unique qui protège les structures de données de contrôle du groupe de mémoires tampons.

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

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

Il s'agit d'un événement d'attente spécifique à la charge de travail. Les principales causes liées à l'apparition de synch/mutex/innodb/buf_pool_mutex sont les suivantes :

• La taille du groupe de mémoires de tampons n'est pas suffisante pour contenir l'ensemble de données de travail.

• La charge de travail est plus spécifique à certaines pages d'une table spécifique de la base de données, ce qui entraîne une contention dans le groupe de mémoires tampons.

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

Pour afficher le graphique Top SQL (Principaux éléments SQL) dans la console de gestion AWS

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.

Utiliser Performance Insights

Cet événement est lié à la charge de travail. Vous pouvez utiliser Performance Insights pour effectuer les opérations suivantes :

• Identifier le moment où les événements d'attente démarrent et si la charge de travail change à ce moment-là à partir des journaux d'application ou des sources associées.

• Identifier les instructions SQL responsables de cet événement d'attente. Examiner le plan d'exécution des requêtes pour vous assurer que ces requêtes sont optimisées et utilisent des index appropriés.

  Si les principales requêtes responsables de l'événement d'attente sont liées au même objet ou table de base de données, pensez à partitionner cet objet ou cette table.

Créer des réplicas Aurora

Vous pouvez créer des réplicas Aurora pour gérer le trafic en lecture seule. Vous pouvez également utiliser Aurora Auto Scaling pour gérer les pics de trafic en lecture. Assurez-vous d'exécuter des tâches planifiées en lecture seule et des sauvegardes logiques sur les réplicas Aurora.

Pour de plus amples informations, veuillez consulter Utilisation d'Amazon Aurora Auto Scaling avec des réplicas Aurora.

Examiner la taille du groupe de mémoires tampons

Vérifiez si la taille du groupe de mémoires tampons est suffisante pour la charge de travail en examinant la métrique innodb_buffer_pool_wait_free. Si la valeur de cette métrique est élevée et augmente continuellement, cela indique que la taille du groupe de mémoires tampons n'est pas suffisante pour gérer la charge de travail. Si innodb_buffer_pool_size a été correctement défini, la valeur de innodb_buffer_pool_wait_free doit être devrait être faible. Pour plus d'informations, consultez Innodb_buffer_pool_wait_free dans la documentation MySQL.

Augmentez la taille du groupe de mémoires tampons si l'instance de base de données dispose de suffisamment de mémoire pour les tampons de session et les tâches du système d'exploitation. Dans le cas contraire, remplacez l'instance de base de données par une classe d'instance de base de données plus grande pour obtenir plus de mémoire à allouer au groupe de mémoires tampons.

Note

Aurora MySQL ajuste automatiquement la valeur innodb_buffer_pool_instances en fonction du paramètre innodb_buffer_pool_size configuré.

Surveiller l'historique global des statuts

La surveillance des taux de modification des variables de statut vous permet de détecter les problèmes de verrouillage ou de mémoire sur votre instance de base de données. Si ce n'est pas déjà fait, activez l'historique global des statuts (GoSH). Pour en savoir plus sur GoSH, consultez Gestion de l'historique global des statuts.

Vous pouvez également créer des métriques Amazon CloudWatch personnalisées afin de surveiller les variables de statut. Pour plus d'informations, consultez Publication de métriques personnalisées.