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.
# Réglage d'Aurora MySQL
Les événements d'attente et les états de thread constituent des outils de réglage importants pour Aurora MySQL. Si vous parvenez à déterminer pourquoi les sessions sont en attente de ressources et ce qu'elles font, vous serez plus à même de réduire les goulots d'étranglement. Vous pouvez utiliser les informations de cette section pour déterminer les causes possibles et les actions correctives à mettre en œuvre.
Amazon DevOps Guru pour RDS peut déterminer de manière proactive si vos bases de données Aurora MySQL rencontrent des problèmes susceptibles de provoquer des problèmes plus graves ultérieurement. Amazon DevOps Guru pour RDS publie une explication et des recommandations concernant les actions correctives dans un insight proactif. Cette section contient des insights sur les problèmes courants.
**Important**
Les événements d'attente et les états de thread présentés dans cette section sont spécifiques à Aurora MySQL. Utilisez les informations de cette section pour régler uniquement Amazon Aurora, et non Amazon RDS for MySQL.
Certains événements d'attente mentionnés dans cette section n'ont pas leur équivalent dans les versions open source de ces moteurs de base de données. D'autres événements d'attente portent le même nom que des événements des moteurs open source, mais se comportent différemment. Par exemple, le stockage Amazon Aurora fonctionne différemment du stockage open source et dès lors, les événements d'attente liés au stockage indiquent des conditions de ressources différentes.
**Topics**
+ [Concepts essentiels à connaître pour le réglage d'Aurora MySQL](AuroraMySQL.Managing.Tuning.concepts.md)
+ [Réglage d'Aurora MySQL avec des événements d'attente](AuroraMySQL.Managing.Tuning.wait-events.md)
+ [Réglage d'Aurora MySQL avec des états de thread](AuroraMySQL.Managing.Tuning.thread-states.md)
+ [Réglage d'Aurora MySQL avec les insights proactifs Amazon DevOps Guru](MySQL.Tuning.proactive-insights.md)
# Concepts essentiels à connaître pour le réglage d'Aurora MySQL
Avant de procéder au réglage de votre base de données Aurora MySQL, vous devez savoir ce que sont les événements d'attente ainsi que les états de thread, et pourquoi ils se produisent. Examinez également l'architecture de base d'Aurora MySQL en termes de mémoire et de disque lorsque vous utilisez le moteur de stockage InnoDB. Un diagramme d'architecture très utile est disponible dans le [Manuel de référence MySQL](https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html).
**Topics**
+ [Événements d'attente Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.waits)
+ [États de thread Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.thread-states)
+ [Mémoire Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.memory)
+ [Processus Aurora MySQL](#AuroraMySQL.Managing.Tuning.concepts.processes)
## Événements d'attente Aurora MySQL
Un *événement d'attente* désigne une ressource pour laquelle une session est en attente. Par exemple, l'événement d'attente `io/socket/sql/client_connection` indique qu'un thread gère une nouvelle connexion. Les ressources généralement attendues par une session sont les suivantes :
+ Accès monothread à une mémoire tampon, par exemple lorsqu'une session tente de modifier une mémoire tampon
+ Ligne verrouillée par une autre session
+ Lecture d'un fichier de données
+ Écriture de fichier journal
Par exemple, pour répondre à une requête, la session peut effectuer une analyse complète de la table. Si les données ne sont pas déjà en mémoire, la session attend la fin des opérations d'I/O disque. Lorsque les mémoires tampons sont lues en mémoire, la session peut être contrainte d'attendre parce que d'autres sessions accèdent aux mêmes mémoires tampons. La base de données enregistre les attentes à l'aide d'un événement d'attente prédéfini. Ces événements sont regroupés en catégories.
En soi, un événement d'attente n'indique pas un problème de performances. Par exemple, si les données demandées ne sont pas en mémoire, il est nécessaire de les lire sur le disque. Si une session verrouille une ligne pour une mise à jour, une autre session attend que la ligne soit déverrouillée pour pouvoir la mettre à jour. Une validation nécessite d'attendre la fin de l'écriture dans un fichier journal. Les attentes font partie intégrante du fonctionnement normal d'une base de données.
Un grand nombre d'événements d'attente indique généralement un problème de performances. Dans ce cas, vous pouvez utiliser les données des événements d'attente pour déterminer où les sessions passent du temps. Par exemple, si plusieurs heures sont désormais nécessaires à l'exécution d'un rapport qui ne prend habituellement que quelques minutes, vous pouvez identifier les événements d'attente qui contribuent le plus au temps d'attente total. La détermination des causes des principaux événements d'attente peut vous permettre d'apporter des modifications qui auront pour effet d'améliorer les performances. Par exemple, si votre session est en attente sur une ligne qui a été verrouillée par une autre session, vous pouvez mettre fin à la session à l'origine du verrouillage.
## États de thread Aurora MySQL
Un *état général de thread* est une valeur `State` associée au traitement général des requêtes. Par exemple, l'état de thread `sending data` indique qu'un thread lit et filtre les lignes d'une requête afin de déterminer l'ensemble de résultats qui convient.
Vous pouvez utiliser les états de thread pour régler Aurora MySQL de la même manière que vous utilisez les événements d'attente. Par exemple, des occurrences fréquentes de `sending data` indiquent généralement qu'une requête n'utilise pas d'index. Pour plus d'informations sur les états de thread, consultez[General Thread States](https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html) dans le *Manuel de référence MySQL*.
Lorsque vous utilisez Performance Insights, l'une des conditions suivantes est vraie :
+ Le schéma de performance est activé : Aurora MySQL affiche les événements d'attente plutôt que l'état de thread.
+ Le schéma de performance n'est pas activé : Aurora MySQL affiche l'état de thread.
Nous vous recommandons de configurer le schéma de performance pour une gestion automatique. Le schéma de performance fournit des informations supplémentaires et de meilleurs outils afin d'examiner les possibles problèmes de performances. Pour en savoir plus, consultez [Présentation du schéma de performance pour Performance Insights sur Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
## Mémoire Aurora MySQL
Dans Aurora MySQL, les zones mémoire les plus importantes sont le groupe de mémoires tampons et la mémoire tampon de journal.
**Topics**
+ [Groupe de mémoires tampons](#AuroraMySQL.Managing.Tuning.concepts.memory.buffer-pool)
### Groupe de mémoires tampons
Le *groupe de mémoires tampons* correspond à la zone de mémoire partagée dans laquelle Aurora MySQL met en cache les données de table et d'index. Les requêtes peuvent accéder aux données fréquemment utilisées directement depuis la mémoire, sans lecture à partir du disque.
Le groupe de mémoires tampons est structuré sous forme de liste liée de pages. Une *page* peut contenir plusieurs lignes. Aurora MySQL utilise un algorithme LRU (Last Recently Used) pour faire vieillir les pages du groupe.
Pour en savoir plus, veuillez consulter [Buffer Pool](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html) dans le *Manuel de référence MySQL*.
## Processus Aurora MySQL
Aurora MySQL utilise un modèle de processus très différent d'Aurora PostgreSQL.
**Topics**
+ [Serveur MySQL (mysqld)](#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)
+ [Threads](#AuroraMySQL.Managing.Tuning.concepts.processes.threads)
+ [Groupe de threads](#AuroraMySQL.Managing.Tuning.concepts.processes.pool)
### Serveur MySQL (mysqld)
Le serveur MySQL est un processus de système d'exploitation unique nommé mysqld. Le serveur MySQL ne génère pas de processus supplémentaires. Ainsi, une base de données Aurora MySQL utilise mysqld pour effectuer la majeure partie de ses tâches.
Lorsque le serveur MySQL démarre, il écoute les connexions réseau des clients MySQL. Lorsqu'un client se connecte à la base de données, mysqld ouvre un thread.
### Threads
Les threads du gestionnaire de connexion associent chaque connexion client à un thread dédié. Ce thread gère l'authentification, exécute des instructions et renvoie les résultats au client. Si nécessaire, le gestionnaire de connexion crée de nouveaux threads.
Le *cache de threads* correspond à l'ensemble de threads disponibles. Lorsqu'une connexion se termine, MySQL renvoie le thread dans le cache de threads si ce dernier n'est pas plein. La variable système `thread_cache_size` détermine la taille du cache de threads.
### Groupe de threads
Le *groupe de threads* se compose de plusieurs groupes de threads. Chaque groupe gère un ensemble de connexions client. Lorsqu'un client se connecte à la base de données, le groupe de threads attribue les connexions aux groupes de threads de manière circulaire. Le groupe de threads sépare les connexions et les threads. Il n'existe aucune relation fixe entre les connexions et les threads exécutant les instructions reçues de ces connexions.
# Réglage d'Aurora MySQL avec des événements d'attente
Le tableau suivant récapitule les événements d'attente Aurora MySQL indiquant le plus souvent des problèmes de performances. Les événements d'attente suivants sont un sous-ensemble de la liste présente dans [Événements d’attente Aurora MySQL](AuroraMySQL.Reference.Waitevents.md).
| Événement d'attente | Description |
| --- | --- |
| [cpu](ams-waits.cpu.md) | Cet événement se produit lorsqu'un thread est actif dans le processeur ou attend le processeur. |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | Cet événement se produit lorsqu'une session écrit des données persistantes dans le stockage Aurora. |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | Cet événement se produit lorsqu'un thread attend de renvoyer un ensemble de résultats à un client. |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | Cet événement se produit lorsqu'une session écrit des données persistantes dans le stockage Aurora. |
| [io/socket/sql/client\$1connexion](ams-waits.client-connection.md) | Cet événement se produit lorsqu'un thread gère une nouvelle connexion. |
| [io/table/sql/handler](ams-waits.waitio.md) | Cet événement se produit lorsque la tâche a été déléguée à un moteur de stockage. |
| [synch/cond/innodb/row\$1bloquer\$1attendre](ams-waits.row-lock-wait.md) | Cet événement se produit lorsqu'une session a verrouillé une ligne pour une mise à jour et qu'une autre session tente de mettre à jour cette même ligne. |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | Cet événement se produit lorsqu'une session a verrouillé une ligne pour une mise à jour et qu'une autre session tente de mettre à jour cette même ligne. |
| [synch/cond/sql/MDL\$1context : :Cond\$1Wait\$1Status](ams-waits.cond-wait-status.md) | Cet événement se produit lorsque des threads sont en attente de verrouillage des métadonnées de table. |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | Cet événement se produit lorsqu'une session a verrouillé une ligne pour une mise à jour et qu'une autre session tente de mettre à jour cette même ligne. |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | Cet événement 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. |
| [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md) | Cet événement se produit lorsqu'une session attend d'accéder à la mémoire cache de l'espace disque logique. |
| [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) | Cet événement se produit lorsque l'activité de base de données est élevée et présente un grand nombre de transactions. |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | Cet événement se produit lorsque des pages introuvables dans le groupe de mémoires tampons doivent être lues à partir d'un fichier. |
| [synch/mutex/innodb/temp\$1pool\$1manager\$1mutex](ams-waits.io-temppoolmanager.md) | Cet événement se produit lorsqu'une session attend d'acquérir un mutex pour gérer le pool de tablespaces temporaires de session. |
# cpu
L'événement d'attente `cpu` se produit lorsqu'un thread est actif dans le processeur ou attend le processeur.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.cpu.context.supported)
+ [Contexte](#ams-waits.cpu.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.cpu.causes)
+ [Actions](#ams-waits.cpu.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
Pour chaque vCPU, une connexion peut exécuter des tâches sur ce processeur. Dans certains cas, le nombre de connexions actives prêtes à être exécutées est supérieur au nombre de CPUs v. Ce déséquilibre se traduit par des connexions en attente de ressources du processeur. Si le nombre de connexions actives reste constamment supérieur au nombre de vCPUs, cela signifie que votre instance est confrontée à un problème de contention du processeur. En cas de contention, l'événement d'attente `cpu` se produit.
**Note**
La métrique Performance Insights pour le processeur est `DBLoadCPU`. La valeur de `DBLoadCPU` peut être différente de la valeur de la CloudWatch métrique`CPUUtilization`. Cette dernière métrique est collectée à partir de HyperVisor pour une instance de base de données.
Les métriques du système d'exploitation Performance Insights fournissent des informations détaillées sur l'utilisation du processeur. Par exemple, vous pouvez afficher les métriques suivantes :
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Performance Insights signale l'utilisation du processeur par le moteur de base de données sous la forme `os.cpuUtilization.nice.avg`.
## Causes probables de l'augmentation du nombre d'événements d'attente
Lorsque cet événement se produit plus que la normale, indiquant un possible problème de performances, les causes types sont les suivantes :
+ Requêtes analytiques
+ Transactions hautement simultanées
+ Transactions de longue durée
+ Augmentation soudaine du nombre de connexions (*tempête de connexions*)
+ Augmentation du changement de contexte
## Actions
Si l'événement d'attente `cpu` domine l'activité de la base de données, cela n'indique pas nécessairement un problème de performance. Ne réagissez à cet événement qu'en cas de dégradation des performances.
Selon la cause de l'augmentation de l'utilisation du processeur, envisagez les stratégies suivantes :
+ Augmentez la capacité du processeur de l'hôte. En règle générale, une telle approche n'apporte qu'un soulagement temporaire.
+ Identifiez les requêtes les plus importantes à des fins d'optimisation potentielle.
+ Redirigez certaines charges de travail en lecture seule vers les nœuds de lecture, le cas échéant.
**Topics**
+ [Identifiez les sessions ou les requêtes à l'origine du problème.](#ams-waits.cpu.actions.az-vpc-subnet)
+ [Analyser et optimiser une charge de travail élevée de l'UC](#ams-waits.cpu.actions.db-instance-class)
### Identifiez les sessions ou les requêtes à l'origine du problème.
Pour trouver les sessions et les requêtes, consultez la table **Top SQL (Principaux éléments SQL)** dans Performance Insights et découvrez les instructions SQL dotées de la charge d'UC la plus élevée. Pour de plus amples informations, veuillez consulter [Analyse des métriques à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.UsingDashboard.md).
En règle générale, une ou deux instructions SQL consomment la majorité des cycles d'UC. Concentrez vos efforts sur ces instructions. Supposons que votre instance de base de données dispose de 2 V CPUs avec une charge de base de données de 3,1 sessions actives (AAS) en moyenne, le tout dans l'état du processeur. Dans ce cas, votre instance est liée à l'UC. Envisagez les stratégies suivantes :
+ Passez à une classe d'instance plus grande avec plus de CPUs v.
+ Réglez vos requêtes pour réduire la charge de l'UC.
Dans cet exemple, les principales requêtes SQL présentent une charge de base de données de 1,5 AAS, toutes à l'état d'UC. Une autre instruction SQL présente une charge de 0,1 à l'état d'UC. Dans cet exemple, si vous arrêtez l'instruction SQL de la charge la plus faible, vous ne réduisez pas la charge de la base de données de manière significative. Toutefois, si vous optimisez les deux requêtes à charge élevée pour qu'elles soient deux fois plus efficaces, vous éliminez le goulet d'étranglement de l'UC. Si vous réduisez la charge de l'UC de 1,5 AAS à hauteur de 50 %, l'AAS de chaque instruction diminue de 0,75. La charge de base de données totale dépensée sur l'UC est désormais de 1,6 AAS. Cette valeur est inférieure à la ligne de vCPU maximale de 2.0.
Pour une présentation de la résolution des problèmes à 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/). Consultez également l'article de AWS support [Comment puis-je résoudre les problèmes liés à l'utilisation élevée du processeur sur mes instances Amazon RDS for](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/) MySQL ? .
### Analyser et optimiser une charge de travail élevée de l'UC
Après avoir identifié la ou les requêtes augmentant l'utilisation de l'UC, vous pouvez les optimiser ou mettre fin à la connexion. L'exemple suivant montre comment mettre fin à une connexion.
```
CALL mysql.rds_kill(processID);
```
Pour de plus amples informations, veuillez consulter [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
Si vous mettez fin à une session, l'action peut déclencher une longue restauration.
#### Suivre les recommandations relatives à l'optimisation des requêtes
Pour optimiser les requêtes, suivez les recommandations ci-dessous :
+ Exécutez l'instruction `EXPLAIN`.
Cette commande affiche les étapes individuelles associées à l'exécution d'une requête. Pour en savoir plus, consultez [Optimizing Queries with EXPLAIN](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html) dans la documentation MySQL.
+ Exécutez l'instruction `SHOW PROFILE`.
Utilisez cette instruction pour consulter les détails du profil pouvant indiquer l'utilisation des ressources pour les instructions exécutées lors de la session en cours. Pour en savoir plus, consultez [SHOW PROFILE Statement](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html) dans la documentation MySQL.
+ Exécutez l'instruction `ANALYZE TABLE`.
Utilisez cette instruction pour actualiser les statistiques d'index des tables accessibles par la requête sollicitant considérablement l'UC. En analysant l'instruction, vous pouvez aider l'optimiseur à choisir un plan d'exécution approprié. Pour en savoir plus, consultez [ANALYZE TABLE Statement](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html) dans la documentation MySQL.
#### Suivez les recommandations pour améliorer l'utilisation de l'UC
Pour améliorer l'utilisation de l'UC dans une instance de base de données, suivez ces recommandations :
+ Assurez-vous que toutes les requêtes utilisent des index appropriés.
+ Voyez si vous pouvez utiliser des requêtes parallèles Aurora. Vous pouvez utiliser cette technique pour réduire l'utilisation de l'UC au niveau du nœud principal grâce au traitement de la fonction « pushdown », au filtrage des lignes et à la projection des colonnes pour la clause `WHERE`.
+ Déterminez si le nombre d'exécutions SQL par seconde atteint les seuils attendus.
+ Déterminez si la maintenance de l'index ou la création d'un nouvel index prend en charge les cycles d'UC nécessaires à votre charge de travail de production. Planifiez les activités de maintenance en dehors des heures de pointe.
+ Déterminez si vous pouvez utiliser le partitionnement pour réduire l'ensemble de données de requête. Pour plus d'informations, consultez le billet de blog.[How to plan and optimize Amazon Aurora with MySQL compatibility for consolidated workloads](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/).
#### Vérifier la présence de tempêtes de connexions
Si la métrique `DBLoadCPU` n'est pas très élevée, mais que la métrique `CPUUtilization` l'est, la cause de l'utilisation élevée de l'UC se situe en dehors du moteur de base de données. La tempête de connexions en est l'illustration type.
Vérifiez si les conditions suivantes sont vraies :
+ Il y a une augmentation à la fois de la `CPUUtilization` métrique Performance Insights et de la CloudWatch `DatabaseConnections` métrique Amazon.
+ Le nombre de threads dans le processeur est supérieur au nombre de CPUs v.
Si les conditions précédentes sont vraies, envisagez de diminuer le nombre de connexions à la base de données. Par exemple, vous pouvez utiliser un groupe de connexions tel que RDS Proxy. Pour connaître les bonnes pratiques en matière de gestion et de mise à l'échelle efficaces des connexions, consultez le livre blanc [Manuel d'administrateur de base de données Amazon Aurora MySQL pour la gestion des connexions](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
# io/aurora\$1redo\$1log\$1flush
L'événement `io/aurora_redo_log_flush` se produit lorsqu'une session écrit des données persistantes sur un stockage Amazon Aurora.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.io-auredologflush.context.supported)
+ [Contexte](#ams-waits.io-auredologflush.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.io-auredologflush.causes)
+ [Actions](#ams-waits.io-auredologflush.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 version 2
## Contexte
L'`io/aurora_redo_log_flush`événement concerne une opération d'écriture input/output (E/S) dans Aurora MySQL.
**Note**
Dans Aurora MySQL version 3, cet événement d’attente s’appelle [io/redo\$1log\$1flush](ams-waits.io-redologflush.md).
## Causes probables de l’augmentation du nombre d’événements d’attente
Pour assurer la persistance des données, les validations nécessitent une écriture durable dans un stockage stable. Si la base de données effectue trop de validations, un événement d'attente se produit lors de l' I/O opération d'écriture, l'événement `io/aurora_redo_log_flush` d'attente.
Dans les exemples suivants, 50 000 enregistrements sont insérés dans un cluster de bases de données Aurora MySQL à l’aide de la classe d’instance de base de données db.r5.xlarge :
+ Dans le premier exemple, chaque session insère 10 000 enregistrements ligne par ligne. Par défaut, en l’absence de commande de langage de manipulation de données (DML) dans une transaction, Aurora MySQL utilise des validations implicites. La validation automatique est activée. Cela signifie qu’une validation accompagne chaque insertion de ligne. Performance Insights montre que les connexions passent l’essentiel de leur temps à attendre sur l’événement d’attente `io/aurora_redo_log_flush`.
![\[Exemple Performance Insights de l’événement d’attente\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
Cela est dû aux simples instructions d’insertion utilisées.
![\[Insérer des instructions dans Top SQL (Principales instructions SQL)\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
L’insertion des 50 000 enregistrements requiert 3,5 minutes.
+ Dans le deuxième exemple, les insertions sont réalisées par lots de 1 000 lots, ce qui signifie que chaque connexion effectue 10 validations au lieu de 10 000. Performance Insights montre que les connexions ne passent pas l’essentiel de leur temps à attendre sur l’événement d’attente `io/aurora_redo_log_flush`.
![\[Exemple Performance Insights de l’événement d’attente présentant moins d’impact\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
L’insertion des 50 000 enregistrements requiert 4 secondes.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [Identifier les sessions et requêtes problématiques](#ams-waits.io-auredologflush.actions.identify-queries)
+ [Regrouper vos opérations d’écriture](#ams-waits.io-auredologflush.actions.action0)
+ [Désactiver la validation automatique](#ams-waits.io-auredologflush.actions.action1)
+ [Utiliser des transactions](#ams-waits.io-auredologflush.action2)
+ [Utiliser des lots](#ams-waits.io-auredologflush.action3)
### Identifier les sessions et requêtes problématiques
Si votre instance de base de données se heure à un goulet d’étranglement, votre première tâche consiste à rechercher les sessions et les requêtes qui en sont à l’origine. Pour un article AWS de blog utile sur les bases de données, consultez [Analyser les charges de travail Amazon Aurora MySQL avec Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**Pour identifier les sessions et les requêtes à l’origine d’un goulet d’étranglement**
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. Sélectionnez votre instance DB.
1. Dans **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)**.
Les requêtes situées en haut de la liste imposent la charge la plus élevée sur la base de données.
### Regrouper vos opérations d’écriture
Les exemples suivants déclenchent l’événement d’attente `io/aurora_redo_log_flush`. (La validation automatique est activée.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Pour réduire le temps passé à attendre sur l’événement d’attente `io/aurora_redo_log_flush`, regroupez logiquement vos opérations d’écriture dans une seule validation et limitez ainsi les appels persistants vers le stockage.
### Désactiver la validation automatique
Désactivez la validation automatique avant d’effectuer d’importantes modifications en dehors d’une transaction, comme le montre l’exemple suivant.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Utiliser des transactions
Vous pouvez utiliser des transactions comme le montre l’exemple suivant.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utiliser des lots
Vous pouvez apporter des modifications par lots, comme le montre l’exemple suivant. Cependant, l'utilisation de lots trop volumineux peut entraîner des problèmes de performances, en particulier lors de la lecture des répliques ou lors de la point-in-time restauration (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
L'événement `io/aurora_respond_to_client` se produit lorsqu'un thread attend de renvoyer un ensemble de résultats à un client.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.respond-to-client.context.supported)
+ [Contexte](#ams-waits.respond-to-client.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.respond-to-client.causes)
+ [Actions](#ams-waits.respond-to-client.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 version 2
## Contexte
L'événement `io/aurora_respond_to_client` indique qu'un thread attend de renvoyer un ensemble de résultats à un client.
Le traitement des requêtes est terminé et les résultats sont renvoyés au client de l'application. Toutefois, la bande passante réseau sur le cluster de bases de données étant insuffisante, un thread attend de renvoyer l'ensemble de résultats.
## Causes probables de l'augmentation du nombre d'événements d'attente
Lorsque l'événement `io/aurora_respond_to_client` se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performance, les causes sont généralement les suivantes :
**Classe d'instance de base de données insuffisante pour la charge de travail**
La classe d'instance de base de données utilisée par le cluster de bases de données ne dispose pas de suffisamment de bande passante réseau pour traiter efficacement la charge de travail.
**Ensembles de résultats volumineux**
La taille de l'ensemble de résultats renvoyé a augmenté, car la requête renvoie un nombre plus élevé de lignes. L'ensemble de résultats plus volumineux consomme davantage de bande passante réseau.
**Charge accrue sur le client**
Le client peut être soumis à une pression exercée sur l'UC, la mémoire ou à une saturation du réseau. Une augmentation de la charge exercée sur le client retarde la réception des données du cluster de bases de données Aurora MySQL.
**Latence réseau accrue**
La latence réseau peut être accrue entre le cluster de bases de données Aurora MySQL et le client. Une latence réseau plus élevée augmente le temps nécessaire au client pour recevoir les données.
## 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.respond-to-client.actions.identify)
+ [Mettre à l'échelle la classe d'instance de base de données](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Vérifier la charge de travail pour trouver des résultats inattendus](#ams-waits.respond-to-client.actions.workload)
+ [Distribuer la charge de travail entre les instances de lecture](#ams-waits.respond-to-client.actions.balance)
+ [Utiliser le modificateur SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### Identifier les sessions et les requêtes à l'origine des événements
Vous pouvez utiliser Performance Insights pour afficher les requêtes bloquées par l'événement d'attente `io/aurora_respond_to_client`. 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 s’affiche pour cette instance de base de données.
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 présentation utile du dépannage à l'aide de Performance Insights, consultez le billet de blog AWS consacré à la base de données [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Mettre à l'échelle la classe d'instance de base de données
Vérifiez l'augmentation de la valeur des CloudWatch métriques Amazon liées au débit du réseau, telles que `NetworkReceiveThroughput` et`NetworkTransmitThroughput`. Si la bande passante réseau de la classe d'instance de base de données est atteinte, vous pouvez mettre à l'échelle la classe d'instance de base de données utilisée par le cluster de bases de données. Une classe d'instance de base de données dotée d'une bande passante réseau plus importante renvoie les données aux clients plus efficacement.
Pour plus d'informations sur le suivi CloudWatch des métriques Amazon, consultez[Affichage des métriques dans la console Amazon RDS](USER_Monitoring.md). Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md). Pour plus d’informations sur la modification d’un cluster de bases de données, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
### Vérifier la charge de travail pour trouver des résultats inattendus
Vérifiez la charge de travail sur le cluster de bases de données et assurez-vous qu'elle ne produit pas de résultats inattendus. Par exemple, certaines requêtes peuvent renvoyer un nombre de lignes plus élevé que prévu. Si tel est le cas, vous pouvez utiliser des métriques de compteur Performance Insights telles que `Innodb_rows_read`. Pour de plus amples informations, veuillez consulter [Métrique de compteur de Performance Insights](USER_PerfInsights_Counters.md).
### Distribuer la charge de travail entre les instances de lecture
Vous pouvez distribuer la charge de travail en lecture seule entre les réplicas Aurora. Vous pouvez procéder à une mise à l'échelle horizontale en ajoutant d'autres réplicas Aurora. Cela peut entraîner une augmentation des limites de bande passante réseau. Pour de plus amples informations, veuillez consulter [Clusters de bases de données Amazon Aurora](Aurora.Overview.md).
### Utiliser le modificateur SQL\$1BUFFER\$1RESULT
Vous pouvez ajouter le modificateur `SQL_BUFFER_RESULT` aux instructions `SELECT` pour forcer les résultats dans une table temporaire avant qu'ils ne soient renvoyés au client. Ce modificateur facilite la résolution des problèmes de performances lorsque les verrous InnoDB ne sont pas libérés, car des requêtes se trouvent dans l'état d'attente `io/aurora_respond_to_client`. Pour en savoir plus, consultez [SELECT Statement](https://dev.mysql.com/doc/refman/5.7/en/select.html) dans la documentation MySQL.
# io/redo\$1log\$1flush
L'événement `io/redo_log_flush` se produit lorsqu'une session écrit des données persistantes sur un stockage Amazon Aurora.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.io-redologflush.context.supported)
+ [Contexte](#ams-waits.io-redologflush.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.io-redologflush.causes)
+ [Actions](#ams-waits.io-redologflush.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 version 3
## Contexte
L'`io/redo_log_flush`événement concerne une opération d'écriture input/output (E/S) dans Aurora MySQL.
**Note**
Dans Aurora MySQL version 2, cet événement d’attente s’appelle [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Causes probables de l’augmentation du nombre d’événements d’attente
Pour assurer la persistance des données, les validations nécessitent une écriture durable dans un stockage stable. Si la base de données effectue trop de validations, un événement d'attente se produit lors de l' I/O opération d'écriture, l'événement `io/redo_log_flush` d'attente.
Pour des exemples du comportement de cet événement d’attente, consultez [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [Identifier les sessions et requêtes problématiques](#ams-waits.io-redologflush.actions.identify-queries)
+ [Regrouper vos opérations d’écriture](#ams-waits.io-redologflush.actions.action0)
+ [Désactiver la validation automatique](#ams-waits.io-redologflush.actions.action1)
+ [Utiliser des transactions](#ams-waits.io-redologflush.action2)
+ [Utiliser des lots](#ams-waits.io-redologflush.action3)
### Identifier les sessions et requêtes problématiques
Si votre instance de base de données se heure à un goulet d’étranglement, votre première tâche consiste à rechercher les sessions et les requêtes qui en sont à l’origine. Pour un article AWS de blog utile sur les bases de données, consultez [Analyser les charges de travail Amazon Aurora MySQL avec Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**Pour identifier les sessions et les requêtes à l’origine d’un goulet d’étranglement**
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. Sélectionnez votre instance DB.
1. Dans **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)**.
Les requêtes situées en haut de la liste imposent la charge la plus élevée sur la base de données.
### Regrouper vos opérations d’écriture
Les exemples suivants déclenchent l’événement d’attente `io/redo_log_flush`. (La validation automatique est activée.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Pour réduire le temps passé à attendre sur l’événement d’attente `io/redo_log_flush`, regroupez logiquement vos opérations d’écriture dans une seule validation et limitez ainsi les appels persistants vers le stockage.
### Désactiver la validation automatique
Désactivez la validation automatique avant d’effectuer d’importantes modifications en dehors d’une transaction, comme le montre l’exemple suivant.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Utiliser des transactions
Vous pouvez utiliser des transactions comme le montre l’exemple suivant.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utiliser des lots
Vous pouvez apporter des modifications par lots, comme le montre l’exemple suivant. Cependant, l'utilisation de lots trop volumineux peut entraîner des problèmes de performances, en particulier lors de la lecture des répliques ou lors de la point-in-time restauration (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
L'événement `io/socket/sql/client_connection` se produit lorsqu'un thread gère une nouvelle connexion.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.client-connection.context.supported)
+ [Contexte](#ams-waits.client-connection.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.client-connection.causes)
+ [Actions](#ams-waits.client-connection.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
L'événement `io/socket/sql/client_connection` indique que mysqld est occupé à créer des threads pour gérer les nouvelles connexions client entrantes. Dans ce scénario, le traitement de la maintenance des nouvelles demandes de connexion client ralentit alors que les connexions attendent l'attribution du thread. Pour de plus amples informations, veuillez consulter [Serveur MySQL (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld).
## Causes probables de l'augmentation du nombre d'événements d'attente
Lorsque cet événement se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performances, les causes sont généralement les suivantes :
+ Le nombre de nouvelles connexions utilisateur entre l'application et votre instance Amazon RDS augmente soudainement.
+ Votre instance de base de données n'est pas en mesure de traiter de nouvelles connexions, car le réseau, le processeur ou la mémoire sont limités.
## Actions
Si `io/socket/sql/client_connection` domine l'activité de la base de données, cela n'indique pas nécessairement un problème de performances. Dans une base de données active, un événement d'attente est toujours en tête. N'intervenez qu'en cas de dégradation des performances. Nous recommandons différentes actions selon les causes de votre événement d'attente.
**Topics**
+ [Identifier les sessions et requêtes problématiques](#ams-waits.client-connection.actions.identify-queries)
+ [Suivre les bonnes pratiques relatives à la gestion des connexions](#ams-waits.client-connection.actions.manage-connections)
+ [Augmenter l'échelle de votre instance en cas de limitation des ressources](#ams-waits.client-connection.upgrade)
+ [Vérifier les hôtes et les utilisateurs principaux](#ams-waits.client-connection.top-hosts)
+ [Interroger les tables performance\$1schema](#ams-waits.client-connection.perf-schema)
+ [Vérifiez l'état des threads de vos requêtes](#ams-waits.client-connection.thread-states)
+ [Auditer vos demandes et requêtes](#ams-waits.client-connection.auditing)
+ [Grouper vos connexions de base de données](#ams-waits.client-connection.pooling)
### Identifier les sessions et requêtes problématiques
Si votre instance de base de données se heure à un goulet d'étranglement, votre première tâche consiste à rechercher les sessions et les requêtes qui en sont à l'origine. Pour un billet de blog particulièrement utile, consultez [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**Pour identifier les sessions et les requêtes à l'origine d'un goulet d'étranglement**
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. Sélectionnez votre instance DB.
1. Dans **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)**.
Les requêtes situées en haut de la liste imposent la charge la plus élevée sur la base de données.
### Suivre les bonnes pratiques relatives à la gestion des connexions
Pour gérer vos connexions, envisagez les stratégies suivantes :
+ Utiliser le regroupement des connexions
Vous pouvez augmenter progressivement le nombre de connexions au fil de vos besoins. Pour plus d'informations, consultez le livre blanc [Manuel de l'administrateur de base de données Amazon Aurora MySQL](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
+ Utilisez un nœud de lecteur pour redistribuer le trafic en lecture seule.
Pour plus d’informations, consultez [Réplicas Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) et [Connexions de point de terminaison Amazon Aurora](Aurora.Overview.Endpoints.md).
### Augmenter l'échelle de votre instance en cas de limitation des ressources
Recherchez des exemples de limitation dans les ressources suivantes :
+ CPU
Vérifiez vos CloudWatch statistiques Amazon pour détecter une utilisation élevée du processeur.
+ Réseau
Vérifiez s'il y a une augmentation de la valeur des CloudWatch métriques `network receive throughput` et`network transmit throughput`. Si votre instance a atteint la limite de bande passante réseau pour votre classe d'instance, pensez à augmenter l'échelle de votre instance RDS vers un type de classe d'instance supérieur. Pour de plus amples informations, veuillez consulter [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md).
+ Mémoire libérable
Vérifiez s'il y a une baisse de la CloudWatch métrique`FreeableMemory`. Pensez également à activer la surveillance améliorée. Pour de plus amples informations, veuillez consulter [Surveillance des métriques du système d’exploitation à l’aide de la Surveillance améliorée](USER_Monitoring.OS.md).
### Vérifier les hôtes et les utilisateurs principaux
Utilisez Performance Insights pour vérifier les hôtes et les utilisateurs principaux. Pour de plus amples informations, veuillez consulter [Analyse des métriques à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.UsingDashboard.md).
### Interroger les tables performance\$1schema
Pour obtenir un comptage précis des connexions actuelles et totales, interrogez les tables `performance_schema`. Cette technique vous permet d'identifier l'utilisateur ou l'hôte source responsable de la création d'un grand nombre de connexions. Par exemple, interrogez les tables `performance_schema` comme suit.
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### Vérifiez l'état des threads de vos requêtes
Si votre problème de performances persiste, vérifiez l'état des threads de vos requêtes. Dans le client `mysql`, exécutez la commande suivante.
```
show processlist;
```
### Auditer vos demandes et requêtes
Pour vérifier la nature des requêtes et des requêtes provenant des comptes utilisateurs, utilisez AuroraAurora MySQL Advanced Auditing. Pour en savoir plus sur l'activation de l'audit, consultez [Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
### Grouper vos connexions de base de données
Pensez à utiliser Amazon RDS Proxy pour gérer les connexions. RDS Proxy vous permet d'autoriser vos applications à grouper et à partager des connexions de bases de données pour améliorer leur capacité de mise à l'échelle. Le proxy RDS rend les applications plus résistantes aux échecs de base de données en les connectant automatiquement à une instance de base de données de secours tout en préservant les connexions des applications. Pour de plus amples informations, veuillez consulter [Proxy Amazon RDS pour Aurora](rds-proxy.md).
# io/table/sql/handler
L’événement `io/table/sql/handler` se produit lorsque la tâche a été déléguée à un moteur de stockage.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.waitio.context.supported)
+ [Contexte](#ams-waits.waitio.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.waitio.causes)
+ [Actions](#ams-waits.waitio.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
L’événement `io/table` indique une attente avant d’accéder à une table. Cet événement se produit indépendamment du fait que les données soient mises en cache dans le groupe de mémoires tampons ou accessibles sur disque. L’événement `io/table/sql/handler` indique une augmentation de l’activité de la charge de travail.
Un *gestionnaire* est une routine spécialisée dans un certain type de données ou axée sur certaines tâches spécifiques. Par exemple, un gestionnaire d’événements reçoit et effectue la synthèse des événements et des signaux issus du système d’exploitation ou d’une interface utilisateur. Un gestionnaire de mémoire effectue des tâches liées à la mémoire. Un gestionnaire d’entrée de fichier est une fonction qui reçoit l’entrée de fichier et effectue des tâches spécifiques sur les données, en fonction du contexte.
Des vues telles que `performance_schema.events_waits_current` indiquent souvent `io/table/sql/handler` lorsque l’attente réelle est un événement d’attente imbriqué tel qu’un verrou. Lorsque l’attente réelle n’est pas `io/table/sql/handler`, Performance Insights signale l’événement d’attente imbriqué. Lorsque Performance Insights publie un rapport`io/table/sql/handler`, cela représente le traitement de la I/O demande par InnoDB et non un événement d'attente imbriqué masqué. Pour plus d’informations, consultez [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) dans le *Manuel de référence MySQL*.
L'`io/table/sql/handler`événement apparaît souvent dans les meilleurs événements d'attente avec des temps d' I/O attente tels que`io/aurora_redo_log_flush`.
## Causes probables de l’augmentation du nombre d’événements d’attente
Dans Performance Insights, des pics soudains de l’événement `io/table/sql/handler` indiquent une augmentation de l’activité de la charge de travail. Une activité accrue traduit une augmentation des I/O.
Performance Insights filtre l'événement d'imbrication IDs et ne signale pas d'`io/table/sql/handler`attente lorsque l'événement imbriqué sous-jacent est une attente bloquée. Par exemple, si l’événement de cause racine est [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), Performance Insights affiche cette attente dans les principaux événements d’attente, et non `io/table/sql/handler`.
Dans des vues telles que `performance_schema.events_waits_current`, les attentes pour `io/table/sql/handler` apparaissent souvent lorsque l’attente réelle est un événement d’attente imbriqué tel qu’un verrou. Lorsque l’attente réelle diffère de `io/table/sql/handler`, Performance Insights recherche l’attente imbriquée et signale l’attente réelle plutôt que `io/table/sql/handler`. Lorsque Performance Insights signale `io/table/sql/handler`, l’attente réelle est `io/table/sql/handler`, et non un événement d’attente imbriqué masqué. Pour plus d’informations, consultez [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) dans le *Manuel de référence MySQL 5.7*.
## Actions
Si cet événement d’attente domine l’activité de la base de données, cela n’indique pas nécessairement un problème de performances. Un événement d’attente est toujours en tête lorsque la base de données est active. Vous ne devez intervenir qu’en cas de dégradation des performances.
Nous recommandons différentes actions en fonction des autres événement d’attente que vous voyez.
**Topics**
+ [Identifier les sessions et les requêtes à l’origine des événements](#ams-waits.waitio.actions.identify)
+ [Vérifier une éventuelle corrélation avec les métriques de compteur Performance Insights](#ams-waits.waitio.actions.filters)
+ [Rechercher d’autres événements d’attente corrélés](#ams-waits.waitio.actions.maintenance)
### 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 s’affiche pour cette instance de base de données.
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 présentation de la résolution des problèmes à 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/).
### Vérifier une éventuelle corrélation avec les métriques de compteur Performance Insights
Vérifiez les métriques de compteur Performance Insights telles que `Innodb_rows_changed`. Si les métriques de compteur sont corrélées avec `io/table/sql/handler`, procédez comme suit :
1. Dans Performance Insights, recherchez les instructions SQL prenant en compte le principal événement d’attente `io/table/sql/handler`. Si possible, optimisez cette instruction de manière à ce qu’elle renvoie moins de lignes.
1. Récupérez les tables principales des vues `schema_table_statistics` et `x$schema_table_statistics`. Ces vues indiquent le temps passé par table. Pour plus d’informations, consultez [The schema\$1table\$1statistics and x\$1schema\$1table\$1statistics Views](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) dans le *Manuel de référence MySQL*.
Par défaut, les lignes sont triées en fonction du temps d’attente total décroissant. Les tables présentant le plus de contention apparaissent en premier. La sortie indique si le temps concerne des lectures, écritures, extractions, insertions, mises à jour ou suppressions.
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### Rechercher d’autres événements d’attente corrélés
Si `synch/sxlock/innodb/btr_search_latch` et `io/table/sql/handler` contribuent le plus à l’anomalie de charge de base de données, vérifiez si la variable `innodb_adaptive_hash_index` est activée. Si tel est le cas, pensez à augmenter la valeur du paramètre `innodb_adaptive_hash_index_parts`.
Si l’index de hachage adaptatif est désactivé, pensez à l’activer. Pour en savoir plus sur l’index de hachage adaptatif MySQL, consultez les ressources suivantes :
+ Article [Is Adaptive Hash Index in InnoDB right for my workload?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload) sur le site Percona
+ [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) dans le*Manuel de référence MySQL*
+ Article [Contention in MySQL InnoDB: Useful Info From the Semaphores Section](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/) sur le site Percona
**Note**
L’index de hachage adaptatif n’est pas pris en charge par les instances de base de données du lecteur Aurora.
Dans certains cas, les performances peuvent être médiocres sur une instance en lecture lorsque `synch/sxlock/innodb/btr_search_latch` et `io/table/sql/handler` sont dominants. Si tel est le cas, pensez à rediriger temporairement la charge de travail vers l’instance de base de données d’enregistreur et à activer l’index de hachage adaptatif.
# synch/cond/innodb/row\$1bloquer\$1attendre
L’événement `synch/cond/innodb/row_lock_wait` se produit lorsqu’une session a verrouillé une ligne pour une mise à jour et qu’une autre session tente de mettre à jour cette même ligne. Pour plus d’informations, consultez [InnoDB Locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) dans la documentation MySQL.
## 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 version 3
## Causes probables de l’augmentation du nombre d’événements d’attente
Plusieurs instructions en langage de manipulation de données (DML) accèdent simultanément aux mêmes lignes.
## Actions
Nous recommandons différentes actions en fonction des autres événement d’attente que vous voyez.
**Topics**
+ [Rechercher et répondre aux instructions SQL responsables de cet événement d’attente](#ams-waits.row-lock-wait.actions.id)
+ [Rechercher et répondre à la session de blocage](#ams-waits.row-lock-wait.actions.blocker)
### Rechercher et répondre aux instructions SQL responsables de cet événement d’attente
Utilisez Performance Insights pour identifier les instructions SQL responsables de cet événement d’attente. Envisagez les stratégies suivantes :
+ Si les verrous de ligne posent un problème persistant, pensez à réécrire l’application de manière à utiliser un verrouillage optimiste.
+ Utiliser plusieurs instructions
+ Répartissez la charge de travail sur différents objets de base de données. Vous pouvez le faire via le partitionnement.
+ Vérifiez la valeur du paramètre `innodb_lock_wait_timeout`. Il contrôle le délai d’attente des transactions avant de générer une erreur de dépassement.
Pour une présentation de la résolution des problèmes à 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/).
### Rechercher et répondre à la session de blocage
Déterminez si la session de blocage est active ou inactive. Vérifiez également si la session provient d’une application ou d’un utilisateur actif.
Pour identifier la session maintenant le verrou, vous pouvez exécuter `SHOW ENGINE INNODB STATUS`. L’exemple suivant illustre une sortie.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Vous pouvez également utiliser la requête suivante pour extraire des détails sur les verrous en cours.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
Après avoir identifié la session, vous pouvez procédez comme suit :
+ Contactez le propriétaire de l’application ou l’utilisateur.
+ Si la session de blocage est inactive, pensez à y mettre fin. Une telle action peut déclencher une longue restauration. Pour savoir comment mettre fin à une session, consultez [Mettre fin à une session ou à une requête](mysql-stored-proc-ending.md).
Pour plus d’informations sur l’identification des transactions de blocage, consultez [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) dans la documentation MySQL.
# synch/cond/innodb/row\$1lock\$1wait\$1cond
L’événement `synch/cond/innodb/row_lock_wait_cond` se produit lorsqu’une session a verrouillé une ligne pour une mise à jour et qu’une autre session tente de mettre à jour cette même ligne. Pour plus d’informations, consultez [InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) dans la documentation MySQL.
## 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 version 2
## Causes probables de l’augmentation du nombre d’événements d’attente
Plusieurs instructions en langage de manipulation de données (DML) accèdent simultanément aux mêmes lignes.
## Actions
Nous recommandons différentes actions en fonction des autres événement d’attente que vous voyez.
**Topics**
+ [Rechercher et répondre aux instructions SQL responsables de cet événement d’attente](#ams-waits.row-lock-wait-cond.actions.id)
+ [Rechercher et répondre à la session de blocage](#ams-waits.row-lock-wait-cond.actions.blocker)
### Rechercher et répondre aux instructions SQL responsables de cet événement d’attente
Utilisez Performance Insights pour identifier les instructions SQL responsables de cet événement d’attente. Envisagez les stratégies suivantes :
+ Si les verrous de ligne posent un problème persistant, pensez à réécrire l’application de manière à utiliser un verrouillage optimiste.
+ Utiliser plusieurs instructions
+ Répartissez la charge de travail sur différents objets de base de données. Vous pouvez le faire via le partitionnement.
+ Vérifiez la valeur du paramètre `innodb_lock_wait_timeout`. Il contrôle le délai d’attente des transactions avant de générer une erreur de dépassement.
Pour une présentation de la résolution des problèmes à 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/).
### Rechercher et répondre à la session de blocage
Déterminez si la session de blocage est active ou inactive. Vérifiez également si la session provient d’une application ou d’un utilisateur actif.
Pour identifier la session maintenant le verrou, vous pouvez exécuter `SHOW ENGINE INNODB STATUS`. L’exemple suivant illustre une sortie.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Vous pouvez également utiliser la requête suivante pour extraire des détails sur les verrous en cours.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Après avoir identifié la session, vous pouvez procédez comme suit :
+ Contactez le propriétaire de l’application ou l’utilisateur.
+ Si la session de blocage est inactive, pensez à y mettre fin. Une telle action peut déclencher une longue restauration. Pour savoir comment mettre fin à une session, consultez [Mettre fin à une session ou à une requête](mysql-stored-proc-ending.md).
Pour plus d’informations sur l’identification des transactions de blocage, consultez [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) dans la documentation MySQL.
# synch/cond/sql/MDL\$1context : :Cond\$1Wait\$1Status
L'événement `synch/cond/sql/MDL_context::COND_wait_status` se produit lorsque des threads sont en attente de verrouillage des métadonnées de table.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.cond-wait-status.context.supported)
+ [Contexte](#ams-waits.cond-wait-status.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.cond-wait-status.causes)
+ [Actions](#ams-waits.cond-wait-status.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
L'événement `synch/cond/sql/MDL_context::COND_wait_status` indique que des threads sont en attente de verrouillage des métadonnées de table. Dans certains cas, une session maintient un verrou de métadonnées sur une table et une autre tente d'obtenir le même verrou sur la même table. Si tel est le cas, la seconde session attend l'événement d'attente `synch/cond/sql/MDL_context::COND_wait_status`.
MySQL utilise le verrouillage des métadonnées pour gérer l'accès simultané aux objets de base de données et assurer la cohérence des données. Le verrouillage des métadonnées s'applique aux tables, schémas, événements planifiés, espaces disque logiques et verrous utilisateur acquis avec la fonction `get_lock` et les programmes stockés. Les programmes stockés incluent des procédures, fonctions et déclencheurs. Pour plus d'informations, consultez [Metadata Locking](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) dans la documentation MySQL.
La liste du processus MySQL affiche cette session dans l'état `waiting for metadata lock`. Dans Performance Insights, si `Performance_schema` est activé, l'événement `synch/cond/sql/MDL_context::COND_wait_status`apparaît.
Le délai d'expiration par défaut d'une requête en attente d'un verrouillage des métadonnées est basé sur la valeur du paramètre `lock_wait_timeout`, qui s'élève par défaut à 31 536 000 secondes (365 jours).
Pour en savoir plus sur les différents verrous InnoDB et les types de verrous susceptibles d'entraîner des conflits, consultez [InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) dans la documentation MySQL.
## Causes probables de l'augmentation du nombre d'événements d'attente
Lorsque l'événement `synch/cond/sql/MDL_context::COND_wait_status` se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performance, les causes sont généralement les suivantes :
**Transactions de longue durée**
Une ou plusieurs transactions modifient une grande quantité de données et maintiennent des verrous sur les tables pendant très longtemps.
**Transactions inactives**
Une ou plusieurs transactions restent ouvertes pendant longtemps, sans être validées ou annulées.
**Instructions DDL sur de grandes tables**
Une ou plusieurs instructions en langage de définition de données (DDL), telles que `ALTER TABLE`, ont été exécutées sur de grandes tables.
**Verrous de table explicites**
Certains verrous de table explicites ne sont pas libérés en temps opportun. Par exemple, une application peut exécuter des instructions `LOCK TABLE` de manière incorrecte.
## Actions
Nous vous recommandons différentes actions en fonction des causes d'apparition de votre événement d'attente et de la version du cluster de bases de données Aurora MySQL.
**Topics**
+ [Identifier les sessions et les requêtes à l'origine des événements](#ams-waits.cond-wait-status.actions.identify)
+ [Rechercher des événements passés](#ams-waits.cond-wait-status.actions.past-events)
+ [Exécuter des requêtes sur Aurora MySQL version 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [Répondre à la session de blocage](#ams-waits.cond-wait-status.actions.blocker)
### Identifier les sessions et les requêtes à l'origine des événements
Vous pouvez utiliser Performance Insights pour afficher les requêtes bloquées par l'événement d'attente `synch/cond/sql/MDL_context::COND_wait_status`. Toutefois, pour identifier la session de blocage, interrogez les tables de métadonnées depuis `performance_schema` et `information_schema` sur le cluster de bases de données.
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 présentation utile du dépannage à l'aide de Performance Insights, consultez le billet de blog AWS consacré à la base de données [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Rechercher des événements passés
Pour obtenir des informations sur cet événement d'attente, vous pouvez rechercher ses précédentes occurrences. Pour ce faire, effectuez les actions suivantes :
+ Vérifiez le langage de manipulation de données (DML), le débit DDL et la latence pour savoir si la charge de travail a changé.
Vous pouvez utiliser Performance Insights pour rechercher des requêtes en attente sur cet événement au moment du problème. Vous pouvez également afficher le résumé des requêtes exécutées à un moment proche du problème.
+ Si les journaux d'audit ou les journaux généraux sont activés pour le cluster de bases de données, vous pouvez rechercher toutes les requêtes exécutées sur les objets (schema.table) impliqués dans la transaction en attente. Vous pouvez également rechercher les requêtes dont l'exécution a pris fin avant la transaction.
Les informations disponibles pour résoudre les problèmes liés aux événements passés sont limitées. L'exécution de ces vérifications n'indique pas quel objet est en attente d'informations. Cela étant, vous pouvez identifier les tables ayant présenté une charge importante au moment de l'événement et l'ensemble de lignes fréquemment utilisées ayant provoqué des conflits au moment du problème. Vous pouvez ensuite utiliser ces informations pour reproduire le problème dans un environnement de test et fournir des informations sur sa cause.
### Exécuter des requêtes sur Aurora MySQL version 2
Dans Aurora MySQL version 2, vous pouvez identifier directement la session bloquée en interrogeant les tables `performance_schema` ou les vues de schéma `sys`. Un exemple permet d'illustrer comment interroger des tables afin d'identifier les requêtes et les sessions de blocage.
Dans la sortie de la liste de processus suivante, l'ID de connexion `89` attend sur un verrou de métadonnées et exécute une commande `TRUNCATE TABLE`. Dans une requête portant sur les tables `performance_schema` ou les vues de schéma `sys`, la sortie indique que la session de blocage est `76`.
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
Ensuite, une requête portant sur les tables `performance_schema` ou les vues de schéma `sys` indique que la session de blocage est `76`.
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### Répondre à la session de blocage
Après avoir identifié la session, vous pouvez procédez comme suit :
+ Contactez le propriétaire de l’application ou l’utilisateur.
+ Si la session de blocage est inactive, pensez à y mettre fin. Une telle action peut déclencher une longue restauration. Pour savoir comment mettre fin à une session, consultez [Mettre fin à une session ou à une requête](mysql-stored-proc-ending.md).
Pour plus d'informations sur l'identification des transactions de blocage, consultez [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) dans la documentation MySQL.
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
L'événement `synch/mutex/innodb/aurora_lock_thread_slot_futex` se produit lorsqu'une session a verrouillé une ligne pour une mise à jour et qu'une autre session tente de mettre à jour cette même ligne. Pour plus d'informations, consultez [InnoDB locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) dans la *Référence MySQL*.
## 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 version 2
## Causes probables de l’augmentation du nombre d’événements d’attente
Plusieurs instructions en langage de manipulation de données (DML) accèdent simultanément aux mêmes lignes.
## Actions
Nous recommandons différentes actions en fonction des autres événement d’attente que vous voyez.
**Topics**
+ [Rechercher et répondre aux instructions SQL responsables de cet événement d’attente](#ams-waits.waitsynch.actions.id)
+ [Rechercher et répondre à la session de blocage](#ams-waits.waitsynch.actions.blocker)
### Rechercher et répondre aux instructions SQL responsables de cet événement d’attente
Utilisez Performance Insights pour identifier les instructions SQL responsables de cet événement d’attente. Envisagez les stratégies suivantes :
+ Si les verrous de ligne posent un problème persistant, pensez à réécrire l’application de manière à utiliser un verrouillage optimiste.
+ Utiliser plusieurs instructions
+ Répartissez la charge de travail sur différents objets de base de données. Vous pouvez le faire via le partitionnement.
+ Vérifiez la valeur du paramètre `innodb_lock_wait_timeout`. Il contrôle le délai d’attente des transactions avant de générer une erreur de dépassement.
Pour une présentation de la résolution des problèmes à 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/).
### Rechercher et répondre à la session de blocage
Déterminez si la session de blocage est active ou inactive. Vérifiez également si la session provient d’une application ou d’un utilisateur actif.
Pour identifier la session maintenant le verrou, vous pouvez exécuter `SHOW ENGINE INNODB STATUS`. L’exemple suivant illustre une sortie.
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
Vous pouvez également utiliser la requête suivante pour extraire des détails sur les verrous en cours.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Après avoir identifié la session, vous pouvez procédez comme suit :
+ Contactez le propriétaire de l’application ou l’utilisateur.
+ Si la session de blocage est inactive, pensez à y mettre fin. Une telle action peut déclencher une longue restauration. Pour savoir comment mettre fin à une session, consultez [Mettre fin à une session ou à une requête](mysql-stored-proc-ending.md).
Pour en savoir plus sur l'identification des transactions de blocage, consultez [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) dans le *Manuel de référence MySQL*.
# synch/mutex/innodb/buf\$1pool\$1mutex
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.
**Topics**
+ [Versions de moteur pertinentes](#ams-waits.bufpoolmutex.context.supported)
+ [Contexte](#ams-waits.bufpoolmutex.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.bufpoolmutex.causes)
+ [Actions](#ams-waits.bufpoolmutex.actions)
## 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](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) 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.
**Topics**
+ [Identifier les sessions et les requêtes à l'origine des événements](#ams-waits.bufpoolmutex.actions.identify)
+ [Utiliser Performance Insights](#ams-waits.bufpoolmutex.actions.action1)
+ [Créer des réplicas Aurora](#ams-waits.bufpoolmutex.actions.action2)
+ [Examiner la taille du groupe de mémoires tampons](#ams-waits.bufpoolmutex.actions.action3)
+ [Surveiller l'historique global des statuts](#ams-waits.bufpoolmutex.actions.action4)
### 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/](https://console.aws.amazon.com/rds/).
1. Dans le volet de navigation, choisissez **Performance Insights**.
1. Choisissez une instance de base de données. Le tableau de bord Performance Insights s'affiche pour cette instance de base de données.
1. Dans le graphique **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**.
1. Sous le graphique **Data load (Charge de base de données)**, 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/).
### 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, consultez [Amazon Aurora Auto Scaling avec des réplicas Aurora](Aurora.Integrating.AutoScaling.md).
### 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\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).
# 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*.
# synch/mutex/innodb/trx\$1sys\$1mutex
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.
**Topics**
+ [Versions de moteur pertinentes](#ams-waits.trxsysmutex.context.supported)
+ [Contexte](#ams-waits.trxsysmutex.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.trxsysmutex.causes)
+ [Actions](#ams-waits.trxsysmutex.actions)
## Versions de moteur pertinentes
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
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. Vous disposez ainsi d'une vue à un instant dans le passé de la base de données lors 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. Une telle 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.
+ Il utilise une structure InnoDB interne appelée `ReadView` qui permet d'identifier les ID de transaction visibles pour un instantané.
## Causes probables de l'augmentation du nombre d'événements d'attente
Toute opération de base de données nécessitant une gestion cohérente et contrôlée (création, lecture, mise à jour et suppression) des ID de transaction génère un appel entre `trx_sys` et 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 [Monitoring InnoDB Mutex Waits Using Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) dans la documentation MySQL.
## 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.trxsysmutex.actions.identify)
+ [Examiner d'autres événements d'attente](#ams-waits.trxsysmutex.actions.action1)
### 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 graphique Top SQL (Principaux éléments SQL) dans la AWS Management Console**
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le volet de navigation, choisissez **Performance Insights**.
1. Choisissez une instance de base de données. Le tableau de bord Performance Insights s'affiche pour cette instance de base de données.
1. Dans le graphique **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**.
1. Sous le graphique **Data load (Charge de base de données)**, 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/).
### 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 en savoir plus sur l'optimisation des transactions, consultez [Optimizing InnoDB Transaction Management](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)dans la documentation MySQL.
# synch/sxlock/innodb/hash\$1table\$1locks
L’événement `synch/sxlock/innodb/hash_table_locks` se produit lorsque des pages introuvables dans le groupe de mémoires tampons doivent être lues à partir d’un fichier.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Contexte](#ams-waits.sx-lock-hash-table-locks.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Actions](#ams-waits.sx-lock-hash-table-locks.actions)
## Versions de moteur prises en charge
Ces informations relatives aux événements d’attente sont prises en charge dans les versions suivantes :
+ Aurora MySQL versions 2 et 3
## Contexte
L’événement `synch/sxlock/innodb/hash_table_locks` indique qu’une charge de travail accède fréquemment à des données qui ne sont pas stockées dans le groupe de mémoires tampons. Cet événement d’attente est associé à des ajouts de nouvelles pages et expulsions d’anciennes données du groupe de mémoires tampons. Les données stockées dans le groupe de mémoires tampons correspondant aux anciennes et nouvelles données doivent être mises en cache pour permettre l’expulsion des anciennes pages et la mise en cache des nouvelles pages. MySQL utilise un algorithme LRU (Last Recently Used) pour expulser les pages du groupe de mémoires tampons. La charge de travail tente d’accéder aux données qui n’ont pas été chargées dans le groupe de mémoires tampons ou aux données qui ont été expulsées de ce dernier.
Cet événement d’attente se produit lorsque la charge de travail doit accéder aux données de fichiers sur disque ou lorsque des blocs sont libérés ou ajoutés à la liste LRU du groupe de mémoires tampons. Ces opérations attendent d’obtenir un verrou partagé exclu (SX-Lock). Ce verrou SX-Lock est utilisé pour la synchronisation sur la *table de hachage*, qui est une table en mémoire conçue pour améliorer les performances d’accès au groupe de mémoires tampons.
Pour plus d’informations, consultez [Buffering and Caching](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html) dans la documentation MySQL.
## Causes probables de l’augmentation du nombre d’événements d’attente
Lorsque l’événement d’attente `synch/sxlock/innodb/hash_table_locks` se produit plus souvent qu’à l’accoutumée, indiquant un possible problème de performance, les causes sont généralement les suivantes :
**Groupe de mémoires tampons sous-dimensionné**
La taille du groupe de mémoires tampons est insuffisante pour conserver en mémoire toutes les pages fréquemment consultées.
**Charge de travail importante**
La charge de travail entraîne de fréquentes expulsions et le rechargement de pages de données dans le cache de tampon.
**Erreurs de lecture des pages**
Le groupe de mémoires tampons présente des erreurs de lectures de pages, ce qui peut indiquer une corruption des données.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [Augmentez la taille du groupe de mémoires tampons](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Améliorer les modèles d’accès aux données](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Réduire ou éviter les analyses de table entière](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Rechercher une éventuelle corruption des pages dans les journaux d’erreurs](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)
### Augmentez la taille du groupe de mémoires tampons
Assurez-vous que le groupe de mémoires tampons est correctement dimensionné pour la charge de travail. Pour ce faire, vous pouvez vérifier le taux d’accès au cache du groupe de mémoires tampons. En règle générale, si la valeur est inférieure à 95 %, envisagez d’augmenter la taille du groupe de mémoires tampons. Un groupe de mémoires tampons plus important peut conserver les pages fréquemment consultées en mémoire plus longtemps. Pour augmenter la taille du groupe de mémoires tampons, modifiez la valeur du paramètre `innodb_buffer_pool_size`. La valeur par défaut de ce paramètre dépend de la taille de la classe d’instance de base de données. Pour plus d’informations, consultez [Bonnes pratiques relatives à la configuration de base de données Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/).
### Améliorer les modèles d’accès aux données
Vérifiez les requêtes affectées par cette attente ainsi que leurs plans d’exécution. Pensez à améliorer les modèles d’accès aux données. Par exemple, si vous utilisez [mysqli\$1result::fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php), vous pouvez essayer d’augmenter la taille d’extraction du tableau.
Vous pouvez utiliser Performance Insights pour afficher les requêtes et les sessions susceptibles d’entraîner l’événement d’attente `synch/sxlock/innodb/hash_table_locks`.
**Pour rechercher les requêtes SQL responsables d’une charge élevée**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Performance Insights**.
1. Choisissez une instance de base de données. Le tableau de bord Performance Insights s’affiche pour cette instance de base de données.
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 présentation de la résolution des problèmes à l’aide de Performance Insights, consultez le billet de blog AWS Database [Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Réduire ou éviter les analyses de table entière
Surveillez votre charge de travail pour voir si elle exécute des analyses de table entière et, si tel est le cas, les réduire ou les éviter. Par exemple, vous pouvez surveiller des variables d’état telles que `Handler_read_rnd_next`. Pour plus d’informations, consultez [Server Status Variables](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next) dans la documentation MySQL.
### Rechercher une éventuelle corruption des pages dans les journaux d’erreurs
Vous pouvez consulter le journal mysql-error.log afin d’y détecter d’éventuels messages de corruption au moment du problème. Les messages à utiliser pour résoudre le problème se trouvent dans le journal des erreurs. Vous devrez peut-être recréer les objets signalés comme corrompus.
# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
L'événement `synch/mutex/innodb/temp_pool_manager_mutex` d'attente se produit lorsqu'une session attend d'acquérir un mutex pour gérer le pool de tablespaces temporaires de session.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.io-temppoolmanager.context.supported)
+ [Contexte](#ams-waits.io-temppoolmanager.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-waits.io-temppoolmanager.causes)
+ [Actions](#ams-waits.io-temppoolmanager.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 version 3
## Contexte
Aurora MySQL version 3.x et versions ultérieures permet `temp_pool_manager_mutex` de contrôler plusieurs sessions accédant simultanément au pool d'espaces de table temporaires. Aurora MySQL gère le stockage via un volume de cluster Aurora pour les données persistantes et le stockage local pour les fichiers temporaires. Un tablespace temporaire est nécessaire lorsqu'une session crée une table temporaire sur le volume du cluster Aurora.
Lorsqu'une session demande pour la première fois un tablespace temporaire, MySQL alloue des tablespaces temporaires de session depuis le pool partagé. Une session peut contenir jusqu'à 2 tablespaces temporaires à la fois pour les types de tables suivants :
+ Tables temporaires créées par l'utilisateur
+ Tables temporaires internes générées par l'optimiseur
Le `TempTable` moteur par défaut utilise le mécanisme de débordement suivant pour gérer les tables temporaires :
+ Stocke les tables dans la RAM jusqu'à la [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)limite.
+ Se déplace vers les fichiers mappés en mémoire sur le stockage local lorsque la RAM est pleine.
+ Utilise le volume de cluster partagé lorsque les fichiers mappés en mémoire atteignent leur limite. [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap)
Lorsque les tables temporaires dépassent à la fois les limites de RAM et de stockage local, MySQL les gère à l'aide d'un espace disque logique.
Lorsqu'une session nécessite une table temporaire sur disque, MySQL :
+ Recherche les `INACTIVE` tablespaces disponibles dans le pool à réutiliser.
+ Crée 10 nouveaux tablespaces s'il n'en existe aucun`INACTIVE`.
Lorsqu'une session se déconnecte, MySQL :
+ Tronque les tablespaces temporaires de la session.
+ Les marque comme INACTIFS dans le pool en vue de leur réutilisation.
+ Maintient la taille actuelle du pool jusqu'au redémarrage du serveur.
+ Revient à la taille du pool par défaut (10 tablespaces) après le redémarrage.
## Causes probables de l’augmentation du nombre d’événements d’attente
Situations courantes à l'origine de cet événement d'attente :
+ Sessions simultanées créant des tables temporaires internes sur le volume du cluster.
+ Sessions simultanées créant des tables temporaires utilisateur sur le volume du cluster.
+ Fin soudaine de sessions utilisant des tablespaces actifs.
+ Expansion du pool de tablespaces lors de lourdes charges d'écriture.
+ Accès aux requêtes simultanées `INFORMATION_SCHEMA.`
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente.
**Topics**
+ [Surveillez et optimisez l'utilisation des tables temporaires](#ams-waits.io-temppoolmanager.actions.monitor)
+ [Révision des requêtes à l'aide de INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [Augmenter le paramètre innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [Implémenter un groupe de connexions](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### Surveillez et optimisez l'utilisation des tables temporaires
Pour surveiller et optimiser l'utilisation des tables temporaires, appliquez l'une des méthodes suivantes :
+ Consultez le `Created_tmp_disk_tables` compteur dans Performance Insights pour suivre la création de tables temporaires sur disque dans votre cluster Aurora.
+ Exécutez cette commande dans votre base de données pour surveiller directement la création de tables temporaires :`mysql> show status like '%created_tmp_disk%'`.
**Note**
Le comportement des tables temporaires diffère entre les nœuds de lecture et d'écriture Aurora MySQL. Pour de plus amples informations, veuillez consulter [Nouveau comportement de table temporaire dans Aurora MySQL version 3](ams3-temptable-behavior.md).
Après avoir identifié les requêtes créant des tables temporaires, suivez les étapes d'optimisation suivantes :
+ `EXPLAIN`À utiliser pour examiner les plans d'exécution des requêtes et identifier où et pourquoi les tables temporaires sont créées.
+ Modifiez les requêtes pour réduire l'utilisation des tables temporaires dans la mesure du possible.
Si l'optimisation des requêtes ne résout pas à elle seule les problèmes de performances, pensez à ajuster les paramètres de configuration suivants :
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)- Contrôle l'utilisation maximale de la RAM pour les tables temporaires.
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap)- Définit la limite pour le stockage de fichiers mappé en mémoire.
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size)- S'applique lorsqu'`aurora_tmptable_enable_per_table_limit`il est activé (désactivé par défaut).
**Important**
Notez que certaines conditions de requête nécessiteront toujours des tables temporaires sur disque, quels que soient les paramètres de configuration. Pour plus d'informations sur le moteur de `TempTable` stockage, consultez [Utiliser le moteur TempTable de stockage sur Amazon RDS for MySQL et Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
### Révision des requêtes à l'aide de INFORMATION\$1SCHEMA
Lorsque vous interrogez `INFORMATION_SCHEMA` des tables, MySQL crée des tables temporaires InnoDB sur le volume du cluster. Chaque session a besoin d'un tablespace temporaire pour ces tables, ce qui peut entraîner des problèmes de performances en cas d'accès simultané élevé.
Pour améliorer les performances :
+ À utiliser `PERFORMANCE_SCHEMA` au lieu de `INFORMATION_SCHEMA` là où c'est possible.
+ Si vous devez en utiliser`INFORMATION_SCHEMA`, réduisez la fréquence à laquelle vous exécutez ces requêtes.
### Augmenter le paramètre innodb\$1sync\$1array\$1size
Le `innodb_sync_array_size` paramètre contrôle la taille du tableau d' mutex/lock attente dans MySQL. La valeur par défaut de `1` fonctionne pour les charges de travail générales, mais son augmentation peut réduire la contention des threads en cas de forte simultanéité.
Lorsque votre charge de travail affiche un nombre croissant de threads en attente :
+ Surveillez le nombre de threads en attente dans votre charge de travail.
+ Définissez un nombre `innodb_sync_array_size` égal ou supérieur au nombre de vCPU de votre instance pour diviser la structure de coordination des threads et réduire les conflits.
**Note**
Pour déterminer le nombre de v CPUs disponibles sur votre instance RDS, consultez les spécifications des vCPU dans les types d'instances [Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Implémenter un groupe de connexions
MySQL attribue un tablespace dédié à chaque session qui crée une table temporaire. Ce tablespace reste actif jusqu'à la fin de la connexion à la base de données. Pour gérer vos ressources de manière plus efficace :
+ Implémentez le regroupement de connexions pour limiter le nombre de tablespaces temporaires actifs.
+ Réutilisez les connexions existantes au lieu d'en créer de nouvelles pour chaque opération.
# Réglage d'Aurora MySQL avec des états de thread
Le table suivant récapitule les états généraux de thread les plus courants pour Aurora MySQL.
| État général de thread | Description |
| --- | --- |
| [creating sort index](ams-states.sort-index.md) | Cet état de thread indique qu'un thread traite une instruction `SELECT` qui requiert l'utilisation d'une table temporaire interne pour trier les données. |
| [envoi de données](ams-states.sending-data.md) | Cet état de thread indique qu'un thread lit et filtre les lignes d'une requête afin de déterminer l'ensemble de résultats qui convient. |
# creating sort index
L’état de thread `creating sort index` pour indique qu’un thread traite une instruction `SELECT` qui requiert l’utilisation d’une table temporaire interne pour trier les données.
**Topics**
+ [Versions de moteur prises en charge](#ams-states.sort-index.context.supported)
+ [Contexte](#ams-states.sort-index.context)
+ [Causes probables de l’augmentation du nombre d’événements d’attente](#ams-states.sort-index.causes)
+ [Actions](#ams-states.sort-index.actions)
## Versions de moteur prises en charge
Ces informations relatives aux états de thread sont prises en charge dans les versions suivantes :
+ Aurora MySQL versions 2 à 2.09.2
## Contexte
L’état `creating sort index` apparaît lorsqu’une requête avec une clause `ORDER BY` ou `GROUP BY` ne peut pas utiliser un index existant pour effectuer l’opération. Dans ce cas, MySQL doit effectuer une opération `filesort` plus coûteuse. Cette opération s’effectue généralement en mémoire si l’ensemble de résultats n’est pas trop volumineux. Sinon, elle implique la création d’un fichier sur disque.
## Causes probables de l’augmentation du nombre d’événements d’attente
L’apparition de `creating sort index` n’indique pas en soi un problème. Si les performances sont médiocres et que les instances de `creating sort index` se multiplient, il y a fort à parier que cela soit dû à la lenteur des requêtes avec les opérateurs `ORDER BY` ou `GROUP BY`.
## Actions
De manière générale, nous vous conseillons de déterminer les requêtes avec des clauses `ORDER BY` ou `GROUP BY` associées aux augmentations de l’état `creating sort index`. Voyez ensuite si l’ajout d’un index ou l’augmentation de la taille du tampon de tri permet de résoudre le problème.
**Topics**
+ [Activer le schéma de performance, le cas échéant](#ams-states.sort-index.actions.enable-pfs)
+ [Identifier les requêtes problématiques](#ams-states.sort-index.actions.identify)
+ [Examiner les plans d’explication de l’utilisation de filesort](#ams-states.sort-index.actions.plan)
+ [Augmenter la taille du tampon de tri](#ams-states.sort-index.actions.increasebuffersize)
### Activer le schéma de performance, le cas échéant
Performance Insights signale les états de thread uniquement si les instruments du schéma de performance ne sont pas activés. Lorsque les instruments du schéma de performance sont activés, Performance Insights signale plutôt les événements d’attente. Les instruments du schéma de performance fournissent des informations supplémentaires et de meilleurs outils pour examiner les possibles problèmes de performances. Par conséquent, nous vous recommandons d’activer le schéma de performance. Pour plus d’informations, consultez [Présentation du schéma de performance pour Performance Insights sur Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
### Identifier les requêtes problématiques
Pour identifier les requêtes actuelles entraînant des augmentations de l’état `creating sort index`, exécutez `show processlist` et vérifiez si l’une des requêtes est accompagnées de `ORDER BY` ou `GROUP BY`. Vous pouvez également exécuter `explain for connection N`, où `N` correspond à l’ID de liste de processus de la requête avec `filesort`.
Pour identifier les requêtes antérieures à l’origine de ces augmentations, activez le journal des requêtes lentes et recherchez les requêtes avec `ORDER BY`. Exécutez `EXPLAIN` sur les requêtes lentes et recherchez « using filesort ». Pour plus d’informations, consultez [Examiner les plans d’explication de l’utilisation de filesort](#ams-states.sort-index.actions.plan).
### Examiner les plans d’explication de l’utilisation de filesort
Identifiez les déclarations accompagnées de clauses `ORDER BY` ou `GROUP BY` aboutissant à l’état `creating sort index`.
L’exemple suivant illustre l’exécution de `explain` sur une requête. La colonne `Extra` indique que cette requête utilise `filesort`.
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2064548
filtered: 100.00
Extra: Using filesort
1 row in set, 1 warning (0.01 sec)
```
L’exemple suivant illustre le résultat de l’exécution de `EXPLAIN` sur la même requête après la création d’un index sur la colonne `c1`.
```
mysql> alter table mytable add index (c1);
```
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: index
possible_keys: NULL
key: c1
key_len: 1023
ref: NULL
rows: 10
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.01 sec)
```
Pour plus d’informations sur l’utilisation des index à des fins d’optimisation de l’ordre de tri, consultez [ORDER BY Optimization](https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html) dans la documentation MySQL.
### Augmenter la taille du tampon de tri
Pour savoir si une requête spécifique a nécessité un processus `filesort` qui a créé un fichier sur disque, vérifiez la valeur de la variable `sort_merge_passes` après l’exécution de la requête. Vous en trouverez un exemple ci-dessous.
```
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
--- run query
mysql> select * from mytable order by u limit 10;
--- run status again:
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
```
Si la valeur de `sort_merge_passes` est élevée, envisagez d’augmenter la taille du tampon de tri. Appliquez l’augmentation au niveau de la session, car une augmentation globale peut considérablement accroître la quantité de RAM utilisée par MySQL. L’exemple suivant montre comment modifier la taille du tampon de tri avant d’exécuter une requête.
```
mysql> set session sort_buffer_size=10*1024*1024;
Query OK, 0 rows affected (0.00 sec)
-- run query
```
# envoi de données
L'état de thread `sending data` indique qu'un thread lit et filtre les lignes d'une requête afin de déterminer l'ensemble de résultats qui convient. Le nom est trompeur car il implique que l'état transfère des données, sans collecter ni préparer les données à envoyer ultérieurement.
**Topics**
+ [Versions de moteur prises en charge](#ams-states.sending-data.context.supported)
+ [Contexte](#ams-states.sending-data.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-states.sending-data.causes)
+ [Actions](#ams-states.sending-data.actions)
## Versions de moteur prises en charge
Ces informations relatives aux états de thread sont prises en charge dans les versions suivantes :
+ Aurora MySQL versions 2 à 2.09.2
## Contexte
De nombreux états de thread sont de courte durée. Les opérations intervenant pendant `sending data` ont tendance à effectuer un grand nombre de lectures de disque ou de cache. Par conséquent, `sending data` est souvent l'état le plus long au cours de la durée de vie d'une requête donnée. Cet état apparaît lorsqu'Aurora MySQL effectue les opérations suivantes :
+ Lecture et traitement de lignes pour une instruction `SELECT`
+ Exécution d'un grand nombre de lectures à partir d'un disque ou d'une mémoire
+ Exécution d'une lecture complète de toutes les données d'une requête spécifique
+ Lecture de données à partir d'une table, d'un index ou du travail d'une procédure stockée
+ Tri, regroupement ou classement des données
Après que l'état `sending data` a terminé de préparer les données, l'état de thread `writing to net` indique le renvoi des données au client. En règle générale, `writing to net` est uniquement capturé lorsque l'ensemble de résultats est très volumineux ou qu'une importante latence réseau ralentit le transfert.
## Causes probables de l'augmentation du nombre d'événements d'attente
L'apparition de `sending data` n'indique pas en soi un problème. Si les performances sont médiocres et que les instances de `sending data` se multiplient, les causes les plus probables sont les suivantes.
**Topics**
+ [Requête inefficace](#ams-states.sending-data.causes.structure)
+ [Configuration sous-optimale du serveur](#ams-states.sending-data.causes.server)
### Requête inefficace
Dans la plupart des cas, cet état découle d'une requête qui n'utilise pas d'index approprié pour trouver l'ensemble de résultats d'une requête spécifique. Par exemple, considérez une requête lisant une table de 10 millions d'enregistrements correspondant à l'ensemble des commandes passées en Californie, où la colonne d'état n'est pas indexée ou mal indexée. Dans ce dernier cas, l'index peut exister, mais l'optimiseur l'ignore en raison de sa faible cardinalité.
### Configuration sous-optimale du serveur
Si plusieurs requêtes apparaissent dans l'état `sending data`, le serveur de base de données peut être mal configuré. Plus précisément, le serveur peut se heurter aux problèmes suivants :
+ La capacité de calcul du serveur de base de données est insuffisante : E/S du disque, type et vitesse du disque, processeur ou nombre de CPUs.
+ Le serveur manque de ressources allouées, telles que le pool de tampons InnoDB pour les tables InnoDB ou le tampon de clés pour les tables. MyIsam
+ Les paramètres de mémoire par thread tels que `sort_buffer`,`read_buffer` et `join_buffer`consomment plus de RAM que nécessaire, privant le serveur physique de ressources mémoire.
## Actions
De manière générale, nous vous conseillons de rechercher les requêtes qui renvoient un grand nombre de lignes en vérifiant le schéma de performance. Si les requêtes de journalisation n'utilisant pas d'index sont activées, vous pouvez également examiner les résultats des journaux lents.
**Topics**
+ [Activer le schéma de performance, le cas échéant](#ams-states.sending-data.actions.enable-pfs)
+ [Examiner les paramètres de mémoire](#ams-states.sending-data.actions.memory)
+ [Examiner les plans d'explication de l'utilisation d'index](#ams-states.sending-data.actions.plans)
+ [Vérifier le volume de données renvoyées](#ams-states.sending-data.actions.maintenance)
+ [Vérifier les problèmes de simultanéité](#ams-states.sending-data.actions.concurrent-queries)
+ [Vérifier la structure de vos requêtes](#ams-states.sending-data.actions.subqueries)
### Activer le schéma de performance, le cas échéant
Performance Insights signale les états de thread uniquement si les instruments du schéma de performance ne sont pas activés. Lorsque les instruments du schéma de performance sont activés, Performance Insights signale plutôt les événements d’attente. Les instruments du schéma de performance fournissent des informations supplémentaires et de meilleurs outils pour examiner les possibles problèmes de performances. Par conséquent, nous vous recommandons d’activer le schéma de performance. Pour de plus amples informations, veuillez consulter [Présentation du schéma de performance pour Performance Insights sur Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
### Examiner les paramètres de mémoire
Examinez les paramètres de mémoire des groupes de mémoires tampons principaux. Assurez-vous que ces groupes de mémoires tampons sont correctement dimensionné pour la charge de travail. Si votre base de données utilise plusieurs instances de groupe de mémoires tampons, assurez-vous qu'elles ne sont pas divisées en petits groupes de mémoires tampons. Les threads ne peuvent utiliser qu'un seul groupe de mémoires tampons à la fois.
Assurez-vous que les paramètres de mémoire suivants utilisés pour chaque thread sont correctement dimensionnés :
+ read\$1buffer
+ read\$1rnd\$1buffer
+ sort\$1buffer
+ join\$1buffer
+ binlog\$1cache
Sauf raison spécifique de les modifier, utilisez les valeurs par défaut des paramètres.
### Examiner les plans d'explication de l'utilisation d'index
Pour les requêtes dans l'état de thread `sending data`, examinez le plan pour déterminer si des index appropriés sont utilisés. Si une requête n'utilise pas d'index utile, envisagez d'ajouter des indicateurs tels que `USE INDEX` ou `FORCE INDEX`. Les indicateurs peuvent considérablement augmenter ou diminuer le délai nécessaire à l'exécution d'une requête et par conséquent, ajoutez-les à bon escient.
### Vérifier le volume de données renvoyées
Vérifiez les tables interrogées et la quantité de données qu'elles contiennent. Certaines de ces données peuvent-elles être archivées ? Très souvent, de piètres délai d'exécution des requêtes ne relèvent pas du plan des requête, mais du volume de données à traiter. De nombreux développeurs ajoutent facilement des données à une base de données, mais rares sont ceux à prendre en compte le cycle de vie des jeux de données lors des phases de conception et de développement.
Recherchez les requêtes qui fonctionnent bien dans les bases de données à faible volume, mais qui fonctionnent nettement moins bien dans votre système actuel. Parfois, les développeurs qui conçoivent des requêtes spécifiques ne réalisent pas que ces requêtes renvoient 350 000 lignes. Les développeurs ont peut-être développé les requêtes dans un environnement à faible volume avec des jeux de données plus petits que ceux des environnements de production.
### Vérifier les problèmes de simultanéité
Vérifiez si plusieurs requêtes de même type sont exécutées en même temps. Certaines formes de requêtes s'exécutent efficacement lorsqu'elles sont exécutées seules. Toutefois, si des formes de requête similaires sont exécutées ensemble ou à un volume élevé, elles peuvent entraîner des problèmes de simultanéité. Ces problèmes surviennent souvent lorsque la base de données utilise des tables temporaires pour afficher les résultats. Un niveau d'isolement restrictif des transactions peut également entraîner des problèmes de simultanéité.
Si les tables sont lues et écrites simultanément, la base de données peut utiliser des verrous. Pour mieux identifier les périodes où les performances sont médiocres, examinez l'utilisation des bases de données via des processus par lots à grande échelle. Pour voir les verrous et restaurations récents, examinez la sortie de la commande `SHOW ENGINE INNODB STATUS`.
### Vérifier la structure de vos requêtes
Vérifiez si les requêtes capturées depuis ces états utilisent des sous-requêtes. Ce type de requête entraîne souvent de mauvaises performances, car la base de données compile les résultats en interne, puis les remplace à nouveau dans la requête pour restituer les données. Ce processus relève d'une étape supplémentaire pour la base de données. Bien souvent, cette étape peut entraîner de mauvaises performances dans des conditions de chargement hautement simultanées.
Vérifiez également si vos requêtes utilisent un grand nombre de clauses `ORDER BY` et `GROUP BY`. Au cours de telles opérations, la base de données doit souvent constituer le jeu de données entier en mémoire. Elle doit ensuite classer ou regrouper ces données de manière spécifique avant de les renvoyer au client.
# Réglage d'Aurora MySQL avec les insights proactifs Amazon DevOps Guru
Les insights proactifs DevOps Guru détectent les conditions problématiques connues sur vos clusters de bases de données Aurora MySQL avant qu'ils se produisent. DevOps Guru peut effectuer les opérations suivantes :
+ Éviter de nombreux problèmes courants liés aux bases de données en recoupant la configuration de votre base de données par rapport aux paramètres courants recommandés.
+ Vous alerter face à des problèmes critiques dans votre flotte qui, s'ils ne sont pas vérifiés, peuvent entraîner des problèmes plus importants ultérieurement.
+ Vous alerter face à des problèmes nouvellement découverts.
Chaque insight proactif contient une analyse de la cause du problème et des recommandations d'actions correctives.
**Topics**
+ [La longueur de la liste d’historique InnoDB a considérablement augmenté](proactive-insights.history-list.md)
+ [La base de données crée des tables temporaires sur le disque](proactive-insights.temp-tables.md)
# La longueur de la liste d’historique InnoDB a considérablement augmenté
À partir de *date* maintenant, votre liste d'historique des modifications de ligne a augmenté de manière significative, jusqu'*length*à un*db-instance*. Cette augmentation affecte les performances d’arrêt des requêtes et des bases de données.
**Topics**
+ [Versions de moteur prises en charge](#proactive-insights.history-list.context.supported)
+ [Contexte](#proactive-insights.history-list.context)
+ [Causes probables de ce problème](#proactive-insights.history-list.causes)
+ [Actions](#proactive-insights.history-list.actions)
+ [Métriques pertinentes](#proactive-insights.history-list.metrics)
## Versions de moteur prises en charge
Ces données d’insight sont prises en charge pour toutes les versions d’Aurora MySQL.
## Contexte
Le système de transaction InnoDB gère le contrôle de simultanéité multiversion (MVCC). Lorsqu’une ligne est modifiée, la version antérieure à la modification des données en cours de modification est stockée sous la forme d’un enregistrement d’annulation dans un journal d’annulation. Chaque enregistrement d’annulation comporte une référence à son enregistrement de rétablissement précédent, formant ainsi une liste liée.
La liste d’historique InnoDB est une liste globale des journaux d’annulation des transactions validées. MySQL utilise cette liste d’historique pour purger les enregistrements et les pages de journal lorsque les transactions n’ont plus besoin de l’historique. La longueur de la liste d’historique est le nombre total de journaux d’annulation contenant des modifications dans la liste d’historique. Chaque journal contient une ou plusieurs modifications. Si la liste d’historique InnoDB devient trop grande, indiquant un grand nombre d’anciennes versions de lignes, les arrêts des bases de données et des requêtes deviennent plus lents.
## Causes probables de ce problème
Les causes typiques d’une longue liste d’historique sont les suivantes :
+ Transactions de longue durée, de lecture ou d’écriture
+ Lourde charge d’écriture
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre insight.
**Topics**
+ [Ne commencer aucune opération impliquant un arrêt de base de données tant que la liste d’historique InnoDB n’a pas diminué](#proactive-insights.history-list.actions.no-shutdown)
+ [Identifier les transactions de longue durée et y mettre fin](#proactive-insights.history-list.actions.long-txn)
+ [Identifier les hôtes et les utilisateurs principaux à l’aide de l’analyse des performances](#proactive-insights.history-list.actions.top-PI)
### Ne commencer aucune opération impliquant un arrêt de base de données tant que la liste d’historique InnoDB n’a pas diminué
Étant donné qu’une longue liste d’historique InnoDB ralentit les arrêts de base de données, réduisez la taille de la liste avant de lancer des opérations impliquant un arrêt de base de données. Ces opérations incluent les mises à niveau des versions majeures de base de données.
### Identifier les transactions de longue durée et y mettre fin
Vous pouvez trouver les transactions de longue durée en exécutant la requête `information_schema.innodb_trx`.
**Note**
Assurez-vous également de rechercher les transactions de longue durée sur les réplicas en lecture.
**Pour identifier les transactions de longue durée et y mettre fin**
1. Dans votre client SQL, exécutez la requête suivante :
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. Terminez chaque transaction de longue durée avec la procédure stockée [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
### Identifier les hôtes et les utilisateurs principaux à l’aide de l’analyse des performances
Optimisez les transactions afin qu’un grand nombre de lignes modifiées soient immédiatement validées.
## Métriques pertinentes
Les métriques suivantes sont liées à cet insight :
+ `trx_rseg_history_len` : cette métrique de compteur peut être consultée dans Performance Insights, ainsi que dans la table `INFORMATION_SCHEMA.INNODB_METRICS`. Pour plus d’informations, consultez [Tableau des métriques InnoDB INFORMATION\$1SCHEMA](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) dans la documentation MySQL.
+ `RollbackSegmentHistoryListLength`— Cette CloudWatch métrique Amazon mesure les journaux d'annulation qui enregistrent les transactions validées avec des enregistrements marqués de suppression. Ces enregistrements sont planifiés pour être traités par l’opération de purge InnoDB. La métrique `trx_rseg_history_len` présente la même valeur que `RollbackSegmentHistoryListLength`.
+ `PurgeBoundary` : le numéro de transaction jusqu’auquel la purge d’InnoDB est autorisée. Si cette CloudWatch métrique n'avance pas pendant de longues périodes, cela indique que la purge d'InnoDB est bloquée par des transactions de longue durée. Pour en savoir plus, vérifiez les transactions actives sur votre cluster de bases de données Aurora MySQL. Cette métrique est prise en charge pour Aurora MySQL versions 2.11 et ultérieures, et 3.08 et ultérieures.
+ `PurgeFinishedPoint` : le numéro de transaction jusqu’auquel la purge d’InnoDB est effectuée. Cette CloudWatch métrique peut vous aider à examiner la rapidité de la purge d'InnoDB. Cette métrique est prise en charge pour Aurora MySQL versions 2.11 et ultérieures, et 3.08 et ultérieures.
+ `TransactionAgeMaximum` : l’âge de la transaction en cours d’exécution active la plus ancienne. Cette CloudWatch métrique n'est disponible que pour Aurora MySQL version 3.08 et supérieure.
+ `TruncateFinishedPoint` : le numéro de transaction jusqu’auquel la troncature d’annulation est effectuée. Cette CloudWatch métrique n'est disponible que pour Aurora MySQL version 2.11 et versions supérieures, et pour les versions 3.08 et supérieures.
Pour plus d'informations sur les CloudWatch métriques, consultez[Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
# La base de données crée des tables temporaires sur le disque
Votre récente utilisation des tables temporaires sur disque a augmenté de manière significative, jusqu'à*percentage*. La base de données crée environ des tables *number* temporaires par seconde. Cela peut avoir un impact sur les performances et augmenter les opérations sur le disque*db-instance*.
**Topics**
+ [Versions de moteur prises en charge](#proactive-insights.temp-tables.context.supported)
+ [Contexte](#proactive-insights.temp-tables.context)
+ [Causes probables de ce problème](#proactive-insights.temp-tables.causes)
+ [Actions](#proactive-insights.temp-tables.actions)
+ [Métriques pertinentes](#proactive-insights.temp-tables.metrics)
## Versions de moteur prises en charge
Ces données d’insight sont prises en charge pour toutes les versions d’Aurora MySQL.
## Contexte
Il est parfois nécessaire que le serveur MySQL crée une table temporaire interne lors du traitement d'une requête. Aurora MySQL peut contenir une table temporaire interne en mémoire, où elle peut être traitée par le moteur de stockage MEMORY TempTable ou stockée sur disque par InnoDB. Pour plus d'informations, consultez [Utilisation des tables temporaires internes dans MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) dans le *manuel de référence de MySQL*.
## Causes probables de ce problème
Une augmentation du nombre de tables temporaires sur disque indique l'utilisation de requêtes complexes. Si la mémoire configurée est insuffisante pour stocker des tables temporaires en mémoire, Aurora MySQL crée les tables sur disque. Cela peut avoir un impact sur les performances et augmenter les opérations sur le disque.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre insight.
+ Pour Aurora MySQL version 3, nous vous recommandons d'utiliser le moteur TempTable de stockage.
+ Optimisez vos requêtes pour renvoyer moins de données en sélectionnant uniquement les colonnes nécessaires.
Si vous activez le schéma de performance alors que tous les instruments `statement` sont activés et temporisés, vous pouvez effectuer une requête `SYS.statements_with_temp_tables` pour récupérer la liste des requêtes utilisant des tables temporaires. Pour plus d'informations, consultez [Prérequis pour l'utilisation du schéma sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) dans la documentation sur MySQL.
+ Envisagez d'indexer les colonnes impliquées dans les opérations de tri et de regroupement.
+ Réécrivez vos requêtes pour éviter les colonnes `BLOB` et `TEXT`. Ces colonnes utilisent toujours un disque.
+ Réglez les paramètres de base de données suivants : `tmp_table_size` et `max_heap_table_size`.
La valeur par défaut de ces paramètres est 16 Mio. Lorsque vous utilisez le moteur de stockage MEMORY pour des tables temporaires en mémoire, leur taille maximale est définie par la plus petite des valeurs `tmp_table_size` et `max_heap_table_size`. Lorsque cette taille maximale est atteinte, MySQL convertit automatiquement la table temporaire interne en mémoire en une table temporaire interne sur disque InnoDB. Pour plus d'informations, consultez [Utiliser le moteur TempTable de stockage sur Amazon RDS for MySQL et Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
**Note**
Lorsque vous créez explicitement des tables MEMORY avec CREATE TABLE, seule la variable `max_heap_table_size` détermine la taille maximale qu'une table peut prendre. Il n'y a pas non plus de conversion vers un format sur disque.
## Métriques pertinentes
Les métriques suivantes d'analyse des performances sont liées à cet insight :
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
Pour plus d'informations, consultez [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) dans la documentation sur MySQL.