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/fil_system_mutex
L'événement synch/mutex/innodb/fil_system_mutex se produit lorsqu'une session attend d'accéder au cache mémoire de l'espace disque logique.
Rubriques
Versions de moteur prises en charge
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
InnoDB utilise des espaces de table pour gérer la zone de stockage des tables et des fichiers journaux. Le cache mémoire de l'espace disque logique est une structure de mémoire globale qui tient à jour les informations relatives aux espaces de table. MySQL utilise les attentes synch/mutex/innodb/fil_system_mutex pour contrôler l'accès simultané au cache mémoire de l'espace disque logique.
L'événement synch/mutex/innodb/fil_system_mutex indique qu'il existe actuellement plusieurs opérations qui doivent récupérer et manipuler des informations dans le cache mémoire de l'espace disque logique pour le même espace de table.
Causes probables de l'augmentation du nombre d'événements d'attente
Lorsque l'événement synch/mutex/innodb/fil_system_mutex se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performance, toutes les conditions suivantes sont généralement réunies :
Augmentation des opérations en langage de manipulation de données (DML) simultanées mettant à jour ou supprimant des données dans la même table.
L'espace disque logique de cette table est très volumineux et contient de nombreuses pages de données.
Le facteur de remplissage de ces pages de données est faible.
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 rechercher les requêtes SQL responsables d'une charge élevée
Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à 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 correspondant à cette instance de base de données s'affiche.
-
Dans le graphique Database load (Charge de base de données), choisissez Slice by wait (Tranche par attente).
-
Au bas de la page, choisissez Top 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
Pour savoir quelles requêtes entraînent un grand nombre d'attentes synch/mutex/innodb/fil_system_mutex, il est également possible de consulter performance_schema, comme dans l'exemple suivant.
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G *************************** 1. row *************************** THREAD_ID: 19 EVENT_ID: 195057 END_EVENT_ID: 195057 EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:6700 TIMER_START: 1010146190118400 TIMER_END: 1010146196524000 TIMER_WAIT: 6405600 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: NULL NESTING_EVENT_TYPE: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL *************************** 2. row *************************** THREAD_ID: 23 EVENT_ID: 5480 END_EVENT_ID: 5480 EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:5906 TIMER_START: 995269979908800 TIMER_END: 995269980159200 TIMER_WAIT: 250400 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: NULL NESTING_EVENT_TYPE: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL *************************** 3. row *************************** THREAD_ID: 55 EVENT_ID: 23233794 END_EVENT_ID: NULL EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:449 TIMER_START: 1010492125341600 TIMER_END: 1010494304900000 TIMER_WAIT: 2179558400 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: 23233786 NESTING_EVENT_TYPE: WAIT OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL
Réorganiser les tables volumineuses pendant les heures creuses
Réorganisez les tables volumineuses que vous identifiez en tant que source d'un nombre élevé d'événements d'attente synch/mutex/innodb/fil_system_mutex pendant une fenêtre de maintenance en dehors des heures de production. Ainsi, le nettoyage des mappages d'espace disque logique interne n'intervient pas lorsqu'un accès rapide à la table est essentiel. Pour plus d'informations sur la réorganisation des tables, consultez OPTIMIZE TABLE Statement
