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/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.
Rubriques
Versions de moteur pertinentes
Ces informations relatives aux événements d'attente sont prises en charge pour les versions de moteur suivantes :
-
Aurora Ma SQL 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 la section Surveillance des attentes d'InnoDB Mutex à l'aide du schéma de performance
Causes probables de l'allongement des temps 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.
Rubriques
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 SQL graphique supérieur dans la console AWS de gestion
Ouvrez la RDS console Amazon à l'adresse https://console.aws.amazon.com/rds/
. -
Dans le volet de navigation, choisissez Performance Insights.
-
Choisissez une instance de base de données. Le tableau de bord Performance Insights s'affiche pour cette instance de base de données.
-
Dans le graphique Database load (Charge de base de données), choisissez Slice by wait (Tranche par attente).
-
Sous le graphique de charge de la base de données, choisissez Top SQL.
Le graphique répertorie les SQL requêtes 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 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
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.
-
Identifiez les SQL déclarations 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 Amazon Aurora Auto Scaling avec des répliques 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 Ma documentation
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 My ajuste SQL automatiquement la valeur de innodb_buffer_pool_instances en fonction de la configurationinnodb_buffer_pool_size.
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 CloudWatch métriques Amazon personnalisées pour surveiller les variables de statut. Pour plus d'informations, consultez Publication de métriques personnalisées.
