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\$1system\$1mutex 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. **Topics** + [Versions de moteur prises en charge](#ams-waits.innodb-fil-system-mutex.context.supported) + [Contexte](#ams-waits.innodb-fil-system-mutex.context) + [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.innodb-fil-system-mutex.causes) + [Actions](#ams-waits.innodb-fil-system-mutex.actions) ## 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. **Topics** + [Identifier les sessions et les requêtes à l'origine des événements](#ams-waits.innodb-fil-system-mutex.actions.identify) + [Réorganiser les tables volumineuses pendant les heures creuses](#ams-waits.innodb-fil-system-mutex.actions.reorganize) ### 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** 1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse. 1. Dans le panneau de navigation, choisissez **Performance Insights**. 1. Choisissez une instance de base de données. Le tableau de bord Performance Insights correspondant à cette instance de base de données s'affiche. 1. Dans le graphique **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**. 1. 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 blog[Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-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](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html) dans la *Référence MySQL*.