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ésolution des problèmes de performances de base de données Amazon Aurora MySQL
Cette rubrique se concentre sur certains problèmes courants de performance des bases de données Aurora MySQL, ainsi que sur la manière de résoudre ces problèmes ou de collecter des informations pour y remédier rapidement. Nous divisons les performances des bases de données en deux catégories principales :
+ Performances du serveur : l’ensemble du serveur de base de données fonctionne plus lentement.
+ Performances des requêtes : l’exécution d’une ou de plusieurs requêtes prend plus de temps.
## Options de surveillance AWS
Nous vous recommandons d’utiliser les options de surveillance AWS suivantes pour faciliter la résolution des problèmes :
+ Amazon CloudWatch : Amazon CloudWatch surveille vos ressources AWS et les applications que vous exécutez sur AWS en temps réel. Vous pouvez utiliser CloudWatch pour recueillir et suivre les métriques, qui sont des variables que vous pouvez mesurer pour vos ressources et applications. Pour plus d’informations, consultez [Qu’est-ce qu’Amazon CloudWatch ?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
Vous pouvez afficher toutes les métriques système et les informations de processus de vos instances de base de données RDS dans la AWS Management Console. Vous pouvez configurer votre cluster de bases de données Aurora MySQL afin qu’il publie les données de journaux généraux, de journaux de requêtes lentes, de journaux d’audit et de journaux d’erreurs dans un groupe de journaux dans Amazon CloudWatch Logs. Cela vous permet de visualiser les tendances, de gérer les journaux si un hôte est impacté et de créer une base de référence pour les performances « normales » afin d’identifier facilement les anomalies ou les modifications. Pour plus d’informations, consultez [Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md).
+ Surveillance améliorée : pour bénéficier de métriques Amazon CloudWatch supplémentaires pour une base de données Aurora MySQL, activez la surveillance améliorée. Lorsque vous créez ou modifiez un cluster de bases de données Aurora, sélectionnez **Activer la surveillance améliorée**. Cela permet à Aurora de publier des métriques de performance sur CloudWatch. Parmi les métriques clés disponibles, citons l’utilisation du processeur, les connexions aux bases de données, l’utilisation du stockage et la latence des requêtes. Ces métriques peuvent vous aider à identifier les goulots d’étranglement au niveau des performances.
La quantité d’informations transférées pour une instance de base de données est directement proportionnelle à la granularité définie pour la fonction de surveillance améliorée. Plus l’intervalle de surveillance est court, plus la fréquence des rapports sur les métriques du système d’exploitation est élevée, ce qui augmente les coûts de surveillance. Pour gérer les coûts, définissez différentes granularités pour différentes instances de vos Comptes AWS. La granularité par défaut lors de la création d’une instance est de 60 secondes. Pour plus d’informations, consultez [Coût de la surveillance améliorée](USER_Monitoring.OS.md#USER_Monitoring.OS.cost).
+ Performance Insights : vous pouvez consulter toutes les métriques relatives aux appels de base de données. Cela inclut les blocages de base de données, les temps d’attente et le nombre de lignes traitées, qui sont tous des informations que vous pouvez utiliser pour la résolution des problèmes. Lorsque vous créez ou modifiez un cluster de bases de données Aurora, sélectionnez **Activer Performance Insights**. Par défaut, Performance Insights dispose d’une période de conservation des données de 7 jours. Toutefois, cette période peut être personnalisée pour permettre une analyse des tendances de performance à long terme. Pour une période de conservation supérieure à 7 jours, vous devez passer à l’offre payante. Pour plus d’informations sur les coûts, consultez [Tarification de Performance Insights](https://aws.amazon.com/rds/performance-insights/pricing/). Vous pouvez définir la période de conservation des données pour chaque instance de base de données Aurora séparément. Pour plus d’informations, consultez [Surveillance de la charge de la base de données avec Performance Insights sur ](USER_PerfInsights.md).
## Causes fréquentes des problèmes de performances des bases de données Aurora MySQL
Vous pouvez suivre les étapes ci-dessous pour résoudre les problèmes de performances dans votre base de données Aurora MySQL. Ces étapes figurent dans l’ordre le plus logique à suivre pour identifier la cause du problème, mais elles ne sont pas censées être linéaires. Une seule découverte peut franchir plusieurs étapes et ouvrir ainsi la voie à une série de pistes d’investigation.
1. [Charge de travail](aurora-mysql-troubleshooting-workload.md) : comprenez la charge de travail de votre base de données.
1. [Journalisation](aurora-mysql-troubleshooting-logging.md) : passez en revue tous les journaux de base de données.
1. [Connexions de base de données](mysql-troubleshooting-dbconn.md) : assurez-vous que les connexions entre vos applications et votre base de données sont fiables.
1. [Performances des requêtes](aurora-mysql-troubleshooting-query.md) : examinez vos plans d’exécution des requêtes pour déterminer s’ils ont changé. Toute modification du code peut entraîner la modification des plans.
# Résolution des problèmes de charge de travail pour les bases de données Aurora MySQL
La charge de travail des bases de données peut être considérée sous forme de lectures et d’écritures. En comprenant la charge de travail « normale » des bases de données, vous pouvez ajuster les requêtes et le serveur de base de données en fonction de l’évolution de la demande. Les performances peuvent changer pour différentes raisons. La première étape consiste donc à comprendre ce qui a changé.
+ Y a-t-il eu une mise à niveau de version majeure ou mineure ?
Une mise à niveau de version majeure inclut des modifications du code du moteur, en particulier dans l’optimiseur, qui peuvent avoir un impact sur le plan d’exécution des requêtes. Lorsque vous mettez à niveau des versions de base de données, notamment des versions majeures, il est très important d’analyser la charge de travail de la base de données et de l’ajuster en conséquence. L’ajustement peut impliquer l’optimisation et la réécriture des requêtes, ou l’ajout et la mise à jour de paramètres, en fonction des résultats des tests. Comprendre la cause de l’impact vous permettra de commencer à vous concentrer sur ce domaine spécifique.
Pour plus d’informations, consultez [Nouveautés de MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) et [Ajout, abandon ou suppression des variables et options de serveur et d’état dans MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html) dans la documentation MySQL, et [Comparaison d’Aurora MySQL version 2 et Aurora MySQL version 3](AuroraMySQL.Compare-v2-v3.md).
+ Y a-t-il eu une augmentation du nombre de données traitées (nombre de lignes) ?
+ D’autres requêtes sont-elles exécutées simultanément ?
+ Y a-t-il des modifications du schéma ou de la base de données ?
+ Y a-t-il eu des défauts ou des corrections de code ?
**Contents**
+ [
## Métriques de l’hôte de l’instance
](#ams-workload-instance)
+ [
### Utilisation de l’UC
](#ams-workload-cpu)
+ [
### Utilisation de la mémoire
](#ams-workload-instance-memory)
+ [
### Débit réseau
](#ams-workload-network)
+ [
## Métriques de base de données
](#ams-workload-db)
+ [
# Résolution des problèmes d’utilisation de la mémoire pour les bases de données Aurora MySQL
](ams-workload-memory.md)
+ [
## Exemple 1 : utilisation élevée de la mémoire en permanence
](ams-workload-memory.md#ams-workload-memory.example1)
+ [
## Exemple 2 : pics de mémoire transitoires
](ams-workload-memory.md#ams-workload-memory.example2)
+ [
## Exemple 3 : la mémoire libérable diminue continuellement et n’est pas récupérée
](ams-workload-memory.md#ams-workload-memory.example3)
+ [
# Résolution des problèmes de mémoire insuffisante pour les bases de données Aurora MySQL
](AuroraMySQLOOM.md)
## Métriques de l’hôte de l’instance
Surveillez les métriques de l’hôte de l’instance telles que le processeur, la mémoire et l’activité réseau afin de déterminer si la charge de travail a changé. Deux concepts principaux permettent de comprendre l’évolution de la charge de travail :
+ Utilisation : utilisation d’un périphérique, tel qu’un processeur ou un disque. Elle peut être basée sur le temps ou sur la capacité.
+ Basée sur le temps : durée pendant laquelle une ressource est occupée au cours d’une période d’observation donnée.
+ Basée sur la capacité : débit qu’un système ou un composant peut fournir, en pourcentage de sa capacité.
+ Saturation : mesure dans laquelle une ressource demande plus de travail qu’elle ne peut en traiter. Lorsque l’utilisation basée sur la capacité atteint 100 %, le travail supplémentaire ne peut pas être traité et doit être mis en file d’attente.
### Utilisation de l’UC
Vous pouvez utiliser les outils suivants pour identifier l’utilisation et la saturation du processeur :
+ CloudWatch fournit la métrique `CPUUtilization`. Si ce chiffre atteint 100 %, l’instance est saturée. Cependant, les métriques CloudWatch se basent sur une moyenne calculée sur une minute et manquent donc de granularité.
Pour plus d’informations sur les métriques CloudWatch, consultez [Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
+ La surveillance améliorée fournit les métriques renvoyées par la commande `top` du système d’exploitation. Elle affiche les moyennes de charge et les états de processeur suivants, avec une granularité d’une seconde :
+ `Idle (%)` = délai d’inactivité
+ `IRQ (%)` = interruptions logicielles
+ `Nice (%)` = moment parfait pour les processus avec une [bonne](https://en.wikipedia.org/wiki/Nice_(Unix)) priorité.
+ `Steal (%)` = temps passé à desservir les autres locataires (lié à la virtualisation)
+ `System (%)` = heure du système
+ `User (%)` = heure de l’utilisateur
+ `Wait (%)` = attente d’E/S
Pour plus d’informations sur les métriques de surveillance améliorée, consultez [Métriques de système d’exploitation pour Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
### Utilisation de la mémoire
Si le système est soumis à une forte charge de mémoire et que la consommation des ressources atteint la saturation, vous devriez observer un taux élevé d’erreurs liées à l’analyse, à la pagination, à l’échange et à l’épuisement de la mémoire.
Vous pouvez utiliser les outils suivants pour identifier l’utilisation et la saturation de la mémoire :
CloudWatch fournit la métrique `FreeableMemory` qui indique la quantité de mémoire pouvant être récupérée en vidant certains caches du système d’exploitation et la mémoire disponible actuellement.
Pour plus d’informations sur les métriques CloudWatch, consultez [Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
La surveillance améliorée fournit les métriques suivantes qui peuvent vous aider à identifier les problèmes d’utilisation de la mémoire :
+ `Buffers (KB)` : quantité de mémoire utilisée pour la mise en mémoire tampon des demandes d’E/S avant écriture dans le périphérique de stockage, en kilo-octets.
+ `Cached (KB)` : quantité de mémoire utilisée pour la mise en cache des E/S basées sur le système de fichiers.
+ `Free (KB)` : quantité de mémoire non attribuée, en kilo-octets.
+ `Swap` : en cache, gratuit et total.
Par exemple, si vous constatez que votre instance de base de données utilise la mémoire `Swap`, la quantité totale de mémoire pour votre charge de travail est supérieure à celle dont dispose actuellement votre instance. Nous vous recommandons d’augmenter la taille de votre instance de base de données ou d’ajuster votre charge de travail pour qu’elle utilise moins de mémoire.
Pour plus d’informations sur les métriques de surveillance améliorée, consultez [Métriques de système d’exploitation pour Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
Pour des informations plus détaillées sur l’utilisation du schéma de performance et du schéma `sys` afin de déterminer les connexions et les composants qui utilisent de la mémoire, consultez [Résolution des problèmes d’utilisation de la mémoire pour les bases de données Aurora MySQL](ams-workload-memory.md).
### Débit réseau
CloudWatch fournit les métriques suivantes concernant le débit total du réseau, toutes calculées en moyenne sur une minute :
+ `NetworkReceiveThroughput` : quantité de débit réseau reçue des clients par chaque instance du cluster de bases de données Aurora.
+ `NetworkTransmitThroughput` : quantité de débit réseau envoyée aux clients par chaque instance du cluster de bases de données Aurora.
+ `NetworkThroughput` : quantité de débit réseau reçue des clients et transmise à ces derniers par chaque instance du cluster de bases de données Aurora.
+ `StorageNetworkReceiveThroughput` : quantité de débit réseau reçue du sous-système de stockage Aurora par chaque instance du cluster de bases de données.
+ `StorageNetworkTransmitThroughput` : quantité de débit réseau envoyée au sous-système de stockage Aurora par chaque instance du cluster de bases de données Aurora.
+ `StorageNetworkThroughput` : quantité de débit réseau reçue du sous-système de stockage Aurora et envoyée à celui-ci par chaque instance du cluster de bases de données Aurora.
Pour plus d’informations sur les métriques CloudWatch, consultez [Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
La surveillance améliorée fournit les graphiques `network` reçus (**RX**) et transmis (**TX**), avec une granularité allant jusqu’à une seconde.
Pour plus d’informations sur les métriques de surveillance améliorée, consultez [Métriques de système d’exploitation pour Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
## Métriques de base de données
Examinez les métriques CloudWatch suivantes pour identifier les modifications de la charge de travail :
+ `BlockedTransactions` : nombre moyen de transactions de la base de données bloquées par seconde.
+ `BufferCacheHitRatio` : pourcentage de demandes traitées par le cache de tampon.
+ `CommitThroughput` : nombre moyen d’opérations de validation par seconde.
+ `DatabaseConnections` : nombre de connexions réseau client à l’instance de base de données.
+ `Deadlocks` : nombre moyen de blocages de la base de données par seconde.
+ `DMLThroughput` : nombre moyen d’insertions, de mises à jour et de suppressions par seconde.
+ `ResultSetCacheHitRatio` : pourcentage de demandes traitées par le cache de requêtes.
+ `RollbackSegmentHistoryListLength` : journaux d’annulation qui enregistrent les transactions validées avec des enregistrements marqués pour la suppression.
+ `RowLockTime` : temps total passé à acquérir des verrous de ligne pour les tables InnoDB.
+ `SelectThroughput` : nombre moyen de requêtes SELECT par seconde.
Pour plus d’informations sur les métriques CloudWatch, consultez [Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
Lorsque vous examinez la charge de travail, posez-vous les questions suivantes :
1. Y a-t-il eu des changements récents dans la classe d’instance de base de données, par exemple une réduction de la taille de l’instance qui serait passé de 8xlarge à 4xlarge, ou le passage de db.r5 à db.r6 ?
1. Peut-on créer un clone et reproduire le problème, ou cela se produit-il uniquement sur cette instance ?
1. Les ressources du serveur sont-elles épuisées, le processeur est-il trop élevé ou la mémoire est-elle saturée ? Dans l’affirmative, cela peut signifier que du matériel supplémentaire est nécessaire.
1. Une ou plusieurs requêtes prennent-elles plus de temps ?
1. Les modifications sont-elles causées par une mise à niveau, en particulier une mise à niveau de version majeure ? Dans l’affirmative, comparez les métriques avant et après la mise à niveau.
1. Y a-t-il des changements du nombre d’instances de base de données en écriture ?
1. Avez-vous activé la journalisation générale, la journalisation d’audit ou la journalisation binaire ? Pour plus d’informations, consultez [Journalisation pour les bases de données Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
1. Avez-vous activé, désactivé ou modifié votre utilisation de la réplication des journaux binaires (binlog) ?
1. Existe-t-il des transactions de longue durée comportant un grand nombre de verrous de ligne ? Examinez la longueur de la liste d’historique (HLL) d’InnoDB pour obtenir des indications sur les transactions de longue durée.
Pour plus d’informations, consultez [La longueur de la liste d’historique InnoDB a considérablement augmenté](proactive-insights.history-list.md) et le billet de blog [Pourquoi ma requête SELECT s’exécute-t-elle lentement sur mon cluster de bases de données Amazon Aurora MySQL ?](https://repost.aws/knowledge-center/aurora-mysql-slow-select-query).
1. Si une grande longueur de la liste d’historique est causée par une transaction d’écriture, cela signifie que les journaux `UNDO` s’accumulent (ils ne sont donc pas nettoyés régulièrement). Dans le cas d’une transaction d’écriture de grande taille, cette accumulation peut augmenter rapidement. Dans MySQL, `UNDO` est stocké dans l’[espace de table SYSTEM](https://dev.mysql.com/doc/refman/5.7/en/innodb-system-tablespace.html). La taille de l’espace de table `SYSTEM` ne peut pas être réduite. Le journal `UNDO` peut entraîner une augmentation de l’espace de table `SYSTEM` pouvant atteindre plusieurs Go, voire plusieurs To. Après la purge, libérez l’espace alloué en effectuant une sauvegarde logique (vidage) des données, puis importez le vidage dans une nouvelle instance de base de données.
1. Si une grande longueur de la liste d’historique est causée par une transaction de lecture (requête de longue durée), cela peut signifier que la requête utilise une grande quantité d’espace temporaire. Libérez l’espace temporaire en effectuant un redémarrage. Examinez les métriques de la base de données Performance Insights pour détecter toute modification dans la section `Temp`, telle que `created_tmp_tables`. Pour plus d’informations, consultez [Surveillance de la charge de la base de données avec Performance Insights sur ](USER_PerfInsights.md).
1. Pouvez-vous diviser les transactions de longue durée en transactions plus petites qui modifient moins de lignes ?
1. Y a-t-il des changements des transactions bloquées ou une augmentation des blocages ? Examinez les métriques de la base de données Performance Insights pour détecter toute modification apportée aux variables d’état dans la section `Locks`, telles que `innodb_row_lock_time`, ` innodb_row_lock_waits` et ` innodb_dead_locks`. Utilisez des intervalles de 1 minute ou de 5 minutes.
1. Y a-t-il une augmentation des temps d’attente ? Examinez les événements et les types d’attente de Performance Insights avec des intervalles de 1 minute ou de 5 minutes. Analysez les principaux événements d’attente et déterminez s’ils sont corrélés à des modifications de la charge de travail ou à des conflits de base de données. Par exemple, `buf_pool mutex` indique un conflit du pool de tampons. Pour plus d’informations, consultez [Réglage d'Aurora MySQL avec des événements d'attente](AuroraMySQL.Managing.Tuning.wait-events.md).
# Résolution des problèmes d’utilisation de la mémoire pour les bases de données Aurora MySQL
CloudWatch, Enhanced Monitoring et Performance Insights fournissent une bonne vue d’ensemble de l’utilisation de la mémoire au niveau du système d’exploitation, notamment de la quantité de mémoire utilisée par le processus de base de données. Cependant, ils ne vous permettent pas de déterminer les connexions ou les composants du moteur susceptibles d’être à l’origine de cette utilisation de mémoire.
Pour résoudre ce problème, vous pouvez utiliser le schéma de performance et le schéma `sys`. Dans Aurora MySQL version 3, l’instrumentation de la mémoire est activée par défaut lorsque le schéma de performance est activé. Dans Aurora MySQL version 2, seule l’instrumentation de la mémoire pour l’utilisation de la mémoire du schéma de performance est activée par défaut. Pour en savoir plus sur les tables disponibles dans le schéma de performance afin de suivre l’utilisation de la mémoire et sur l’activation de l’instrumentation de la mémoire du schéma de performance, consultez [Memory Summary Tables](https://dev.mysql.com/doc/refman/8.3/en/performance-schema-memory-summary-tables.html) dans la documentation MySQL. Pour plus d’informations sur l’utilisation du schéma de performance avec Performance Insights, consultez [Présentation du schéma de performance pour Performance Insights sur Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
Bien que des informations détaillées soient disponibles dans le schéma de performance pour suivre l’utilisation actuelle de la mémoire, le [schéma système](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) MySQL inclut des vues au-dessus des tables du schéma de performance. Ces vues vous permettent d’identifier rapidement où la mémoire est utilisée.
Dans le schéma `sys`, les vues suivantes sont disponibles pour suivre l’utilisation de la mémoire par connexion, composant et requête.
| Vue | Description |
| --- | --- |
| [memory\$1by\$1host\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-host-by-current-bytes.html) | Fournit des informations sur l’utilisation de la mémoire du moteur par hôte. Cette vue peut être utile pour identifier les serveurs d’applications ou les hôtes clients qui consomment de la mémoire. |
| [memory\$1by\$1thread\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-thread-by-current-bytes.html) | Fournit des informations sur l’utilisation de la mémoire du moteur par ID de thread. L’ID de thread dans MySQL peut être une connexion client ou un thread d’arrière-plan. Vous pouvez mapper les ID de thread aux ID de connexion MySQL en utilisant la vue [sys.processlist](https://dev.mysql.com/doc/refman/8.0/en/sys-processlist.html) ou la table [performance\$1schema.threads](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-threads-table.html). |
| [memory\$1by\$1user\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-user-by-current-bytes.html) | Fournit des informations sur l’utilisation de la mémoire du moteur par utilisateur. Cette vue peut être utile pour identifier les comptes utilisateurs ou les clients consommant de la mémoire. |
| [memory\$1global\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-global-by-current-bytes.html) | Fournit des informations sur l’utilisation de la mémoire du moteur par composant du moteur. Cette vue peut être utile pour identifier l’utilisation globale de la mémoire par les tampons ou les composants du moteur. Par exemple, vous pouvez voir l’événement `memory/innodb/buf_buf_pool` pour le pool de tampons InnoDB ou l’événement `memory/sql/Prepared_statement::main_mem_root` pour les instructions préparées. |
| [memory\$1global\$1total](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-global-total.html) | Fournit une vue d’ensemble de l’utilisation totale de la mémoire suivie dans le moteur de base de données. |
Dans Aurora MySQL 3.05 et versions ultérieures, vous pouvez également suivre l’utilisation maximale de la mémoire par résumé d’instruction dans les [tableaux récapitulatifs des instructions du schéma de performance](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html). Les tableaux récapitulatifs des instructions contiennent des résumés d’instructions normalisés et des statistiques agrégées sur leur exécution. La colonne `MAX_TOTAL_MEMORY` peut vous aider à identifier la mémoire maximale utilisée par le résumé des requêtes depuis la dernière réinitialisation des statistiques ou depuis le redémarrage de l’instance de base de données. Cela peut être utile pour identifier des requêtes spécifiques susceptibles de consommer beaucoup de mémoire.
**Note**
Le schéma de performance et le schéma `sys` indiquent l’utilisation actuelle de la mémoire sur le serveur, ainsi que le maximum de mémoire consommée par connexion et par composant du moteur. Le schéma de performance étant conservé en mémoire, les informations sont réinitialisées au redémarrage de l’instance de base de données. Pour en conserver un historique au fil du temps, nous vous recommandons de configurer la récupération et le stockage de ces données en dehors du schéma de performance.
**Topics**
+ [
## Exemple 1 : utilisation élevée de la mémoire en permanence
](#ams-workload-memory.example1)
+ [
## Exemple 2 : pics de mémoire transitoires
](#ams-workload-memory.example2)
+ [
## Exemple 3 : la mémoire libérable diminue continuellement et n’est pas récupérée
](#ams-workload-memory.example3)
## Exemple 1 : utilisation élevée de la mémoire en permanence
En examinant `FreeableMemory` dans CloudWatch, nous constatons que l’utilisation de la mémoire a considérablement augmenté le 26/03/2024 à 02:59 UTC.
![\[Graphe FreeableMemory montrant une utilisation élevée de la mémoire.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ams-freeable-memory.png)
Nous ne disposons toutefois pas de toutes les informations requises. Pour déterminer quel composant utilise le plus de mémoire, vous pouvez vous connecter à la base de données et consulter `sys.memory_global_by_current_bytes`. Cette table contient une liste des événements de mémoire suivis par MySQL, ainsi que des informations sur l’allocation de mémoire par événement. Chaque événement de suivi de la mémoire commence par `memory/%`, suivi d’autres informations sur le composant ou la fonctionnalité du moteur auquel l’événement est associé.
Par exemple, `memory/performance_schema/%` indique les événements de mémoire liés au schéma de performance, `memory/innodb/%` correspond à InnoDB, etc. Pour plus d’informations sur les conventions de dénomination utilisées dans les événements, consultez [Performance Schema Instrument Naming Conventions](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) dans la documentation MySQL.
Dans la requête suivante, nous pouvons identifier le responsable le plus probable en fonction de `current_alloc`, mais nous constatons également la présence de nombreux événements `memory/performance_schema/%`.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB |
| memory/performance_schema/prepared_statements_instances | 252 | 488.25 MiB | 1.94 MiB | 252 | 488.25 MiB | 1.94 MiB |
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 1028 | 52.27 MiB | 52.06 KiB | 1028 | 52.27 MiB | 52.06 KiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 4 | 47.25 MiB | 11.81 MiB | 4 | 47.25 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB |
| memory/performance_schema/memory_summary_by_thread_by_event_name | 4 | 31.64 MiB | 7.91 MiB | 4 | 31.64 MiB | 7.91 MiB |
| memory/innodb/memory | 15227 | 27.44 MiB | 1.85 KiB | 20619 | 33.33 MiB | 1.66 KiB |
| memory/sql/String::value | 74411 | 21.85 MiB | 307 bytes | 76867 | 25.54 MiB | 348 bytes |
| memory/sql/TABLE | 8381 | 21.03 MiB | 2.57 KiB | 8381 | 21.03 MiB | 2.57 KiB |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.02 sec)
```
Nous avons mentionné précédemment que le schéma de performance est stocké en mémoire, ce qui signifie qu’il est également suivi dans l’instrumentation de la mémoire `performance_schema`.
**Note**
Si vous constatez que le schéma de performance utilise beaucoup de mémoire et que vous souhaitez limiter son utilisation, vous pouvez ajuster les paramètres de base de données en fonction de vos besoins. Pour plus d’informations, consultez [The Performance Schema Memory-Allocation Model](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-memory-model.html) dans la documentation MySQL.
Pour une meilleure lisibilité, vous pouvez réexécuter la même requête, mais exclure les événements du schéma de performance. Voici les informations que nous donne le résultat :
+ Le principal consommateur de mémoire est `memory/sql/Prepared_statement::main_mem_root`.
+ La colonne `current_alloc` nous indique que MySQL dispose actuellement de 4,91 Gio alloués à cet événement.
+ `high_alloc column` indique que 4,91 Gio est le seuil maximum de `current_alloc` depuis la dernière réinitialisation des statistiques ou depuis le redémarrage du serveur. Autrement dit, `memory/sql/Prepared_statement::main_mem_root` a atteint sa valeur la plus élevée.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name NOT LIKE 'memory/performance_schema/%' LIMIT 10;
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB |
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/innodb/memory | 17096 | 31.68 MiB | 1.90 KiB | 22498 | 37.60 MiB | 1.71 KiB |
| memory/sql/String::value | 122277 | 27.94 MiB | 239 bytes | 124699 | 29.47 MiB | 247 bytes |
| memory/sql/TABLE | 9927 | 24.67 MiB | 2.55 KiB | 9929 | 24.68 MiB | 2.55 KiB |
| memory/innodb/lock0lock | 8888 | 19.71 MiB | 2.27 KiB | 8888 | 19.71 MiB | 2.27 KiB |
| memory/sql/Prepared_statement::infrastructure | 257623 | 16.24 MiB | 66 bytes | 257631 | 16.24 MiB | 66 bytes |
| memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB |
| memory/innodb/sync0arr | 3 | 7.03 MiB | 2.34 MiB | 3 | 7.03 MiB | 2.34 MiB |
| memory/sql/THD::main_mem_root | 815 | 6.56 MiB | 8.24 KiB | 849 | 7.19 MiB | 8.67 KiB |
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.06 sec)
```
Le nom de l’événement révèle que cette mémoire est utilisée pour des instructions préparées. Pour déterminer quelles connexions utilisent cette mémoire, vérifiez [memory\$1by\$1thread\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-thread-by-current-bytes.html).
Dans l’exemple suivant, environ 7 Mio sont alloués à chaque connexion, avec un seuil maximum d’environ 6,29 Mio (`current_max_alloc`). Cela est logique, car cet exemple utilise `sysbench` avec 80 tables et 800 connexions avec des instructions préparées. Si vous souhaitez réduire l’utilisation de la mémoire dans ce scénario, vous pouvez optimiser l’utilisation des instructions préparées par votre application afin de limiter la consommation de la mémoire.
```
mysql> SELECT * FROM sys.memory_by_thread_by_current_bytes;
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| thread_id | user | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| 46 | rdsadmin@localhost | 405 | 8.47 MiB | 21.42 KiB | 8.00 MiB | 155.86 MiB |
| 61 | reinvent@10.0.4.4 | 1749 | 6.72 MiB | 3.93 KiB | 6.29 MiB | 14.24 MiB |
| 101 | reinvent@10.0.4.4 | 1845 | 6.71 MiB | 3.72 KiB | 6.29 MiB | 14.50 MiB |
| 55 | reinvent@10.0.4.4 | 1674 | 6.68 MiB | 4.09 KiB | 6.29 MiB | 14.13 MiB |
| 57 | reinvent@10.0.4.4 | 1416 | 6.66 MiB | 4.82 KiB | 6.29 MiB | 13.52 MiB |
| 112 | reinvent@10.0.4.4 | 1759 | 6.66 MiB | 3.88 KiB | 6.29 MiB | 14.17 MiB |
| 66 | reinvent@10.0.4.4 | 1428 | 6.64 MiB | 4.76 KiB | 6.29 MiB | 13.47 MiB |
| 75 | reinvent@10.0.4.4 | 1389 | 6.62 MiB | 4.88 KiB | 6.29 MiB | 13.40 MiB |
| 116 | reinvent@10.0.4.4 | 1333 | 6.61 MiB | 5.08 KiB | 6.29 MiB | 13.21 MiB |
| 90 | reinvent@10.0.4.4 | 1448 | 6.59 MiB | 4.66 KiB | 6.29 MiB | 13.58 MiB |
| 98 | reinvent@10.0.4.4 | 1440 | 6.57 MiB | 4.67 KiB | 6.29 MiB | 13.52 MiB |
| 94 | reinvent@10.0.4.4 | 1433 | 6.57 MiB | 4.69 KiB | 6.29 MiB | 13.49 MiB |
| 62 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.48 MiB |
| 87 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.25 MiB |
| 99 | reinvent@10.0.4.4 | 1346 | 6.54 MiB | 4.98 KiB | 6.29 MiB | 13.24 MiB |
| 105 | reinvent@10.0.4.4 | 1347 | 6.54 MiB | 4.97 KiB | 6.29 MiB | 13.34 MiB |
| 73 | reinvent@10.0.4.4 | 1335 | 6.54 MiB | 5.02 KiB | 6.29 MiB | 13.23 MiB |
| 54 | reinvent@10.0.4.4 | 1510 | 6.53 MiB | 4.43 KiB | 6.29 MiB | 13.49 MiB |
. .
. .
. .
| 812 | reinvent@10.0.4.4 | 1259 | 6.38 MiB | 5.19 KiB | 6.29 MiB | 13.05 MiB |
| 214 | reinvent@10.0.4.4 | 1279 | 6.38 MiB | 5.10 KiB | 6.29 MiB | 12.90 MiB |
| 325 | reinvent@10.0.4.4 | 1254 | 6.38 MiB | 5.21 KiB | 6.29 MiB | 12.99 MiB |
| 705 | reinvent@10.0.4.4 | 1273 | 6.37 MiB | 5.13 KiB | 6.29 MiB | 13.03 MiB |
| 530 | reinvent@10.0.4.4 | 1268 | 6.37 MiB | 5.15 KiB | 6.29 MiB | 12.92 MiB |
| 307 | reinvent@10.0.4.4 | 1263 | 6.37 MiB | 5.17 KiB | 6.29 MiB | 12.87 MiB |
| 738 | reinvent@10.0.4.4 | 1260 | 6.37 MiB | 5.18 KiB | 6.29 MiB | 13.00 MiB |
| 819 | reinvent@10.0.4.4 | 1252 | 6.37 MiB | 5.21 KiB | 6.29 MiB | 13.01 MiB |
| 31 | innodb/srv_purge_thread | 17810 | 3.14 MiB | 184 bytes | 2.40 MiB | 205.69 MiB |
| 38 | rdsadmin@localhost | 599 | 1.76 MiB | 3.01 KiB | 1.00 MiB | 25.58 MiB |
| 1 | sql/main | 3756 | 1.32 MiB | 367 bytes | 355.78 KiB | 6.19 MiB |
| 854 | rdsadmin@localhost | 46 | 1.08 MiB | 23.98 KiB | 1.00 MiB | 5.10 MiB |
| 30 | innodb/clone_gtid_thread | 1596 | 573.14 KiB | 367 bytes | 254.91 KiB | 970.69 KiB |
| 40 | rdsadmin@localhost | 235 | 245.19 KiB | 1.04 KiB | 128.88 KiB | 808.64 KiB |
| 853 | rdsadmin@localhost | 96 | 94.63 KiB | 1009 bytes | 29.73 KiB | 422.45 KiB |
| 36 | rdsadmin@localhost | 33 | 36.29 KiB | 1.10 KiB | 16.08 KiB | 74.15 MiB |
| 33 | sql/event_scheduler | 3 | 16.27 KiB | 5.42 KiB | 16.04 KiB | 16.27 KiB |
| 35 | sql/compress_gtid_table | 8 | 14.20 KiB | 1.77 KiB | 8.05 KiB | 18.62 KiB |
| 25 | innodb/fts_optimize_thread | 12 | 1.86 KiB | 158 bytes | 648 bytes | 1.98 KiB |
| 23 | innodb/srv_master_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 24.40 KiB |
| 24 | innodb/dict_stats_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 1.35 KiB |
| 5 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes |
| 6 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes |
| 2 | sql/aws_oscar_log_level_monitor | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 4 | innodb/io_ibuf_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 7 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 8 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 9 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 10 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 11 | innodb/srv_lra_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 12 | innodb/srv_akp_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 18 | innodb/srv_lock_timeout_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 248 bytes |
| 19 | innodb/srv_error_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 20 | innodb/srv_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 21 | innodb/buf_resize_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 22 | innodb/btr_search_sys_toggle_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 32 | innodb/dict_persist_metadata_table_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 34 | sql/signal_handler | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
831 rows in set (2.48 sec)
```
Comme indiqué précédemment, la valeur de l’ID de thread (`thd_id`) ici peut faire référence aux threads d’arrière-plan du serveur ou aux connexions à la base de données. Si vous souhaitez associer les valeurs des ID de thread aux ID de connexion à la base de données, vous pouvez utiliser la table `performance_schema.threads` ou la vue `sys.processlist`, où `conn_id` correspond à l’ID de connexion.
```
mysql> SELECT thd_id,conn_id,user,db,command,state,time,last_wait FROM sys.processlist WHERE user='reinvent@10.0.4.4';
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
| thd_id | conn_id | user | db | command | state | time | last_wait |
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
| 590 | 562 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 578 | 550 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 579 | 551 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 580 | 552 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 581 | 553 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 582 | 554 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 583 | 555 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 584 | 556 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 585 | 557 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 586 | 558 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 587 | 559 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
. .
. .
. .
| 323 | 295 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 324 | 296 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 325 | 297 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 326 | 298 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 438 | 410 | reinvent@10.0.4.4 | sysbench | Execute | System lock | 0 | wait/lock/table/sql/handler |
| 280 | 252 | reinvent@10.0.4.4 | sysbench | Sleep | starting | 0 | wait/io/socket/sql/client_connection |
| 98 | 70 | reinvent@10.0.4.4 | sysbench | Query | freeing items | 0 | NULL |
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
804 rows in set (5.51 sec)
```
Nous arrêtons maintenant la charge de travail `sysbench`, qui ferme les connexions et libère de la mémoire. En vérifiant à nouveau les événements, nous pouvons confirmer que la mémoire est libérée, mais `high_alloc` nous indique tout de même quel est le seuil maximum. La colonne `high_alloc` peut être très utile pour identifier de courts pics d’utilisation de la mémoire, contrairement à `current_alloc`, qui indique uniquement la mémoire actuellement allouée.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10;
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 512823 | 4.91 GiB | 10.04 KiB |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
1 row in set (0.00 sec)
```
Si vous souhaitez réinitialiser `high_alloc`, vous pouvez tronquer les tableaux récapitulatifs de la mémoire `performance_schema`, mais toute l’instrumentation de la mémoire sera réinitialisée. Pour plus d’informations, consultez [Performance Schema General Table Characteristics](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-table-characteristics.html) dans la documentation MySQL.
Dans l’exemple suivant, nous pouvons voir que `high_alloc` est réinitialisé après la troncature.
```
mysql> TRUNCATE `performance_schema`.`memory_summary_global_by_event_name`;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10;
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 17 | 253.80 KiB | 14.93 KiB |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
1 row in set (0.00 sec)
```
## Exemple 2 : pics de mémoire transitoires
Les courts pics d’utilisation de la mémoire sur un serveur de base de données constituent un autre phénomène courant. Il peut s’agir de baisses périodiques de mémoire libérable difficiles à gérer avec `sys.memory_global_by_current_bytes` dans `current_alloc`, car la mémoire a déjà été libérée.
**Note**
Si les statistiques du schéma de performance ont été réinitialisées ou si l’instance de base de données a été redémarrée, ces informations ne seront pas disponibles dans `sys` ni p`erformance_schema`. Pour conserver ces informations, nous vous recommandons de configurer la collecte de métriques externes.
Le graphique suivant de la métrique `os.memory.free` dans Surveillance améliorée présente de courts pics d’utilisation de la mémoire de 7 secondes. La section Surveillance améliorée vous permet de surveiller l’utilisation à des intervalles pouvant atteindre une seconde, ce qui est parfait pour détecter ce type de pic transitoire.
![\[Graphique illustrant les pics transitoires d’utilisation de la mémoire au fil du temps, avec un schéma récurrent indiquant des problèmes potentiels de gestion de la mémoire.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ams-free-memory-spikes.png)
Pour aider à diagnostiquer la cause de l’utilisation de la mémoire, nous pouvons utiliser à la fois `high_alloc` dans les vues récapitulatives de la mémoire `sys` et les [tableaux récapitulatifs des instructions du schéma de performance](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html) afin d’essayer d’identifier les sessions et les connexions problématiques.
Comme prévu, étant donné que l’utilisation de la mémoire n’est pas élevée actuellement, nous ne voyons aucun responsable majeur dans la vue du schéma `sys`, sous`current_alloc`.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/innodb/os0event | 439372 | 60.34 MiB | 144 bytes | 439372 | 60.34 MiB | 144 bytes |
| memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB |
| memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB |
| memory/performance_schema/events_statements_history_long | 1 | 14.34 MiB | 14.34 MiB | 1 | 14.34 MiB | 14.34 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 257 | 13.07 MiB | 52.06 KiB | 257 | 13.07 MiB | 52.06 KiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 1 | 11.81 MiB | 11.81 MiB | 1 | 11.81 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.sql_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.01 sec)
```
En élargissant la vue pour effectuer un tri par `high_alloc`, nous constatons que le composant `memory/temptable/physical_ram` est très probablement responsable de l’utilisation élevée de la mémoire. À son maximum, il consommait 515,00 Mio.
Comme son nom l’indique, `memory/temptable/physical_ram` instrumente l’utilisation de la mémoire pour le moteur de stockage `TEMP` de MySQL, introduit dans MySQL 8.0. Pour plus d’informations sur la façon dont MySQL utilise les tables temporaires, consultez [Internal temporary table use in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) dans la documentation MySQL.
**Note**
Nous utilisons la vue `sys.x$memory_global_by_current_bytes` dans cet exemple.
```
mysql> SELECT event_name, format_bytes(current_alloc) AS "currently allocated", sys.format_bytes(high_alloc) AS "high-water mark"
FROM sys.x$memory_global_by_current_bytes ORDER BY high_alloc DESC LIMIT 10;
+-----------------------------------------------------------------------------+---------------------+-----------------+
| event_name | currently allocated | high-water mark |
+-----------------------------------------------------------------------------+---------------------+-----------------+
| memory/temptable/physical_ram | 4.00 MiB | 515.00 MiB |
| memory/innodb/hash0hash | 79.07 MiB | 79.07 MiB |
| memory/innodb/os0event | 63.95 MiB | 63.95 MiB |
| memory/performance_schema/events_statements_summary_by_digest | 40.28 MiB | 40.28 MiB |
| memory/mysys/KEY_CACHE | 16.00 MiB | 16.00 MiB |
| memory/performance_schema/events_statements_history_long | 14.34 MiB | 14.34 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 13.07 MiB | 13.07 MiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 11.81 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest.digest_text | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.sql_text | 9.77 MiB | 9.77 MiB |
+-----------------------------------------------------------------------------+---------------------+-----------------+
10 rows in set (0.00 sec)
```
Dans[Exemple 1 : utilisation élevée de la mémoire en permanence](#ams-workload-memory.example1), nous avons vérifié l’utilisation actuelle de la mémoire pour chaque connexion afin de déterminer quelle connexion est responsable de l’utilisation de la mémoire en question. Dans cet exemple, la mémoire est déjà libérée. Il n’est donc pas utile de vérifier l’utilisation de la mémoire pour les connexions en cours.
Pour aller plus loin dans notre recherche et trouver les instructions, les utilisateurs et les hôtes problématiques, utilisons le schéma de performance. Le schéma de performance contient plusieurs tableaux récapitulatifs des instructions divisés en différentes dimensions, telles que le nom de l’événement, le résumé de l’instruction, l’hôte, le thread et l’utilisateur. Chaque vue vous permet de mieux comprendre où certaines instructions sont exécutées et ce qu’elles font. Cette section se concentre sur `MAX_TOTAL_MEMORY`, mais vous trouverez plus d’informations sur toutes les colonnes disponibles dans la documentation [Tableaux récapitulatifs des instructions du schéma de performance](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html).
```
mysql> SHOW TABLES IN performance_schema LIKE 'events_statements_summary_%';
+------------------------------------------------------------+
| Tables_in_performance_schema (events_statements_summary_%) |
+------------------------------------------------------------+
| events_statements_summary_by_account_by_event_name |
| events_statements_summary_by_digest |
| events_statements_summary_by_host_by_event_name |
| events_statements_summary_by_program |
| events_statements_summary_by_thread_by_event_name |
| events_statements_summary_by_user_by_event_name |
| events_statements_summary_global_by_event_name |
+------------------------------------------------------------+
7 rows in set (0.00 sec)
```
Vérifions d’abord `events_statements_summary_by_digest` pour voir `MAX_TOTAL_MEMORY`.
Nous en tirons les informations suivantes :
+ La requête avec le résumé `20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a` semble être un responsable probable de cette utilisation de la mémoire. `MAX_TOTAL_MEMORY` indique 537450710, ce qui correspond au seuil maximum que nous avons observé pour l’événement `memory/temptable/physical_ram` dans `sys.x$memory_global_by_current_bytes`.
+ Elle a été exécutée quatre fois (`COUNT_STAR`): la première fois le 26/03/2024 04:08:34.943256, et la dernière fois le 26/03/2024 04:43:06.998310.
```
mysql> SELECT SCHEMA_NAME,DIGEST,COUNT_STAR,MAX_TOTAL_MEMORY,FIRST_SEEN,LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest ORDER BY MAX_TOTAL_MEMORY DESC LIMIT 5;
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
| SCHEMA_NAME | DIGEST | COUNT_STAR | MAX_TOTAL_MEMORY | FIRST_SEEN | LAST_SEEN |
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
| sysbench | 20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a | 4 | 537450710 | 2024-03-26 04:08:34.943256 | 2024-03-26 04:43:06.998310 |
| NULL | f158282ea0313fefd0a4778f6e9b92fc7d1e839af59ebd8c5eea35e12732c45d | 4 | 3636413 | 2024-03-26 04:29:32.712348 | 2024-03-26 04:36:26.269329 |
| NULL | 0046bc5f642c586b8a9afd6ce1ab70612dc5b1fd2408fa8677f370c1b0ca3213 | 2 | 3459965 | 2024-03-26 04:31:37.674008 | 2024-03-26 04:32:09.410718 |
| NULL | 8924f01bba3c55324701716c7b50071a60b9ceaf17108c71fd064c20c4ab14db | 1 | 3290981 | 2024-03-26 04:31:49.751506 | 2024-03-26 04:31:49.751506 |
| NULL | 90142bbcb50a744fcec03a1aa336b2169761597ea06d85c7f6ab03b5a4e1d841 | 1 | 3131729 | 2024-03-26 04:15:09.719557 | 2024-03-26 04:15:09.719557 |
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
5 rows in set (0.00 sec)
```
Maintenant que nous connaissons le résumé problématique, nous pouvons obtenir plus d’informations telles que le texte de la requête, l’utilisateur qui l’a exécutée et l’endroit où elle a été exécutée. Grâce au texte du résumé renvoyé, nous voyons qu’il s’agit d’une expression de table commune (CTE) qui crée quatre tables temporaires et effectue quatre analyses de tables, ce qui est très inefficace.
```
mysql> SELECT SCHEMA_NAME,DIGEST_TEXT,QUERY_SAMPLE_TEXT,MAX_TOTAL_MEMORY,SUM_ROWS_SENT,SUM_ROWS_EXAMINED,SUM_CREATED_TMP_TABLES,SUM_NO_INDEX_USED
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST='20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a'\G;
*************************** 1. row ***************************
SCHEMA_NAME: sysbench
DIGEST_TEXT: WITH RECURSIVE `cte` ( `n` ) AS ( SELECT ? FROM `sbtest1` UNION ALL SELECT `id` + ? FROM `sbtest1` ) SELECT * FROM `cte`
QUERY_SAMPLE_TEXT: WITH RECURSIVE cte (n) AS ( SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte
MAX_TOTAL_MEMORY: 537450710
SUM_ROWS_SENT: 80000000
SUM_ROWS_EXAMINED: 80000000
SUM_CREATED_TMP_TABLES: 4
SUM_NO_INDEX_USED: 4
1 row in set (0.01 sec)
```
Pour plus d’informations sur la table `events_statements_summary_by_digest` et les autres tableaux récapitulatifs des instructions du schéma de performance, consultez [Statement summary tables](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html) dans la documentation MySQL.
Vous pouvez également exécuter une instruction [EXPLAIN](https://dev.mysql.com/doc/refman/8.0/en/explain.html) ou [EXPLAIN ANALYZE](https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze) pour obtenir plus de détails.
**Note**
L’instruction `EXPLAIN ANALYZE` peut fournir plus d’informations que `EXPLAIN`, mais elle exécute également la requête. Vous devez donc être prudent.
```
-- EXPLAIN
mysql> EXPLAIN WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte;
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
| 1 | PRIMARY | | NULL | ALL | NULL | NULL | NULL | NULL | 19221520 | 100.00 | NULL |
| 2 | DERIVED | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index |
| 3 | UNION | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index |
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)
-- EXPLAIN format=tree
mysql> EXPLAIN format=tree WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G;
*************************** 1. row ***************************
EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6)
-> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6)
-> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6)
-> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6)
1 row in set (0.00 sec)
-- EXPLAIN ANALYZE
mysql> EXPLAIN ANALYZE WITH RECURSIVE cte (n) AS (SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G;
*************************** 1. row ***************************
EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) (actual time=6666..9201 rows=20e+6 loops=1)
-> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) (actual time=6666..6666 rows=20e+6 loops=1)
-> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0365..2006 rows=10e+6 loops=1)
-> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0311..2494 rows=10e+6 loops=1)
1 row in set (10.53 sec)
```
Mais qui l’a exécutée ? Dans le schéma de performance, nous pouvons voir que l’utilisateur `destructive_operator` a atteint la valeur `MAX_TOTAL_MEMORY` 537450710, ce qui correspond aux résultats précédents.
**Note**
Comme le schéma de performance est stocké en mémoire, il ne doit pas être considéré comme la seule source d’audit. Si vous devez conserver un historique des instructions exécutées et des utilisateurs qui les ont exécutées, nous vous recommandons d’activer l’[audit avancé avec Aurora](AuroraMySQL.Auditing.md). Si vous devez également conserver des informations sur l’utilisation de la mémoire, nous vous recommandons de configurer la surveillance afin d’exporter et de stocker ces valeurs.
```
mysql> SELECT USER,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_user_by_event_name
ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5;
+----------------------+---------------------------+------------+------------------+
| USER | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY |
+----------------------+---------------------------+------------+------------------+
| destructive_operator | statement/sql/select | 4 | 537450710 |
| rdsadmin | statement/sql/select | 4172 | 3290981 |
| rdsadmin | statement/sql/show_tables | 2 | 3615821 |
| rdsadmin | statement/sql/show_fields | 2 | 3459965 |
| rdsadmin | statement/sql/show_status | 75 | 1914976 |
+----------------------+---------------------------+------------+------------------+
5 rows in set (0.00 sec)
mysql> SELECT HOST,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_host_by_event_name
WHERE HOST != 'localhost' AND COUNT_STAR>0 ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5;
+------------+----------------------+------------+------------------+
| HOST | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY |
+------------+----------------------+------------+------------------+
| 10.0.8.231 | statement/sql/select | 4 | 537450710 |
+------------+----------------------+------------+------------------+
1 row in set (0.00 sec)
```
## Exemple 3 : la mémoire libérable diminue continuellement et n’est pas récupérée
Le moteur de base de données InnoDB utilise divers événements de suivi de mémoire spécialisés pour différents composants. Ces événements spécifiques permettent un suivi granulaire de l’utilisation de la mémoire dans les principaux sous-systèmes InnoDB, par exemple :
+ `memory/innodb/buf0buf` — Dédié à la surveillance des allocations de mémoire pour le pool de tampons InnoDB.
+ `memory/innodb/ibuf0ibuf` — Suit spécifiquement les modifications de mémoire liées au tampon de modification d’InnoDB.
Pour identifier les principaux consommateurs de mémoire, nous pouvons interroger `sys.memory_global_by_current_bytes` :
```
mysql> SELECT event_name,current_alloc FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------+---------------+
| event_name | current_alloc |
+-----------------------------------------------------------------+---------------+
| memory/innodb/memory | 5.28 GiB |
| memory/performance_schema/table_io_waits_summary_by_index_usage | 495.00 MiB |
| memory/performance_schema/table_shares | 488.00 MiB |
| memory/sql/TABLE_SHARE::mem_root | 388.95 MiB |
| memory/innodb/std | 226.88 MiB |
| memory/innodb/fil0fil | 198.49 MiB |
| memory/sql/binlog_io_cache | 128.00 MiB |
| memory/innodb/mem0mem | 96.82 MiB |
| memory/innodb/dict0dict | 96.76 MiB |
| memory/performance_schema/rwlock_instances | 88.00 MiB |
+-----------------------------------------------------------------+---------------+
10 rows in set (0.00 sec)
```
Les résultats révèlent que `memory/innodb/memory` est le principal consommateur, lequel utilise 5,28 Gio sur la mémoire actuellement allouée. Cet événement sert de catégorie pour les allocations de mémoire entre divers composants InnoDB non associés à des événements d’attente plus spécifiques, comme `memory/innodb/buf0buf` mentionné précédemment.
Après avoir établi que les composants InnoDB sont les principaux consommateurs de mémoire, nous pouvons approfondir notre recherche à l’aide de la commande MySQL suivante :
```
SHOW ENGINE INNODB STATUS \G;
```
La commande [SHOW ENGINE INNODB STATUS](https://dev.mysql.com/doc/refman/8.4/en/show-engine.html) fournit un rapport d’état complet pour le moteur de stockage InnoDB, y compris des statistiques détaillées d’utilisation de la mémoire pour les différents composants InnoDB. Il contribue à identifier les structures ou opérations InnoDB spécifiques qui consomment le plus de mémoire. Pour plus d’informations, consultez [InnoDB In-Memory Structures](https://dev.mysql.com/doc/refman/8.0/en/innodb-in-memory-structures.html) dans la documentation MySQL.
En analysant la section `BUFFER POOL AND MEMORY` du rapport d’état d’InnoDB, nous constatons que 5 051 647 748 octets (4,7 Gio) sont alloués au [cache d’objets du dictionnaire](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-object-cache.html), ce qui représente 89 % de la mémoire suivie par `memory/innodb/memory`.
```
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 0
Dictionary memory allocated 5051647748
Buffer pool size 170512
Free buffers 142568
Database pages 27944
Old database pages 10354
Modified db pages 6
Pending reads 0
```
Le cache d’objets du dictionnaire est un cache global partagé qui stocke en mémoire les objets du dictionnaire de données qui ont déjà été consultés afin de permettre leur réutilisation et d’améliorer les performances. L’allocation de mémoire élevée pour le cache d’objets du dictionnaire suggère qu’un grand nombre d’objets de base de données se trouve dans le cache.
Maintenant que nous savons que le cache du dictionnaire de données est l’un des principaux consommateurs, nous allons l’inspecter pour détecter les tables ouvertes. Pour connaître le nombre de tables ouvertes dans le cache de définition de table, interrogez la variable d’état globale [open\$1table\$1definitions](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html#statvar_Open_table_definitions).
```
mysql> show global status like 'open_table_definitions';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| Open_table_definitions | 20000 |
+------------------------+-------+
1 row in set (0.00 sec)
```
Pour plus d’informations, consultez [How MySQL Opens and Closes Tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html) dans la documentation MySQL.
Vous pouvez restreindre le nombre de définitions de tables dans le cache du dictionnaire de données en limitant le paramètre `table_definition_cache` dans le groupe de paramètres du cluster de bases de données ou de l’instance de base de données. Pour Aurora MySQL, cette valeur joue le rôle de limite flexible pour le nombre de tables dans le cache de définition de table. La valeur par défaut dépend de la classe d’instance et est définie comme suit :
```
LEAST({DBInstanceClassMemory/393040}, 20000)
```
Lorsque le nombre de tables dépasse la limite `table_definition_cache`, un mécanisme basé sur les éléments les moins récemment utilisés, ou LRU, évacue et supprime des tables du cache. Toutefois, les tables impliquées dans les relations de clé étrangère ne sont pas placées dans la liste LRU, ce qui empêche leur suppression.
Dans notre scénario actuel, nous exécutons [FLUSH TABLES](https://dev.mysql.com/doc/refman/8.4/en/flush.html) pour vider le cache de définition de table. Cette action entraîne une baisse significative de la variable d’état globale [Open\$1Table\$1Definitions](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Open_table_definitions), qui passe de 20 000 à 12, comme indiqué ici :
```
mysql> show global status like 'open_table_definitions';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| Open_table_definitions | 12 |
+------------------------+-------+
1 row in set (0.00 sec)
```
Malgré cette réduction, nous observons que l’allocation de mémoire pour `memory/innodb/memory` de 5,18 Gio reste élevée, et que la mémoire allouée au dictionnaire reste également inchangée. Cela ressort clairement des résultats de requête suivants :
```
mysql> SELECT event_name,current_alloc FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------+---------------+
| event_name | current_alloc |
+-----------------------------------------------------------------+---------------+
| memory/innodb/memory | 5.18 GiB |
| memory/performance_schema/table_io_waits_summary_by_index_usage | 495.00 MiB |
| memory/performance_schema/table_shares | 488.00 MiB |
| memory/sql/TABLE_SHARE::mem_root | 388.95 MiB |
| memory/innodb/std | 226.88 MiB |
| memory/innodb/fil0fil | 198.49 MiB |
| memory/sql/binlog_io_cache | 128.00 MiB |
| memory/innodb/mem0mem | 96.82 MiB |
| memory/innodb/dict0dict | 96.76 MiB |
| memory/performance_schema/rwlock_instances | 88.00 MiB |
+-----------------------------------------------------------------+---------------+
10 rows in set (0.00 sec)
```
```
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 0
Dictionary memory allocated 5001599639
Buffer pool size 170512
Free buffers 142568
Database pages 27944
Old database pages 10354
Modified db pages 6
Pending reads 0
```
Cette utilisation constamment élevée de la mémoire peut être attribuée aux tables impliquées dans des relations de clé étrangère. Ces tables ne sont pas placées dans la liste LRU de tables à supprimer, ce qui explique pourquoi l’allocation de mémoire reste élevée même après avoir vidé le cache de définition de table.
Pour résoudre ce problème :
1. Passez en revue et optimisez le schéma de votre base de données, en particulier les relations de clé étrangère.
1. Envisagez de passer à une classe d’instance de base de données plus vaste qui dispose de plus de mémoire pour héberger les objets de votre dictionnaire.
En suivant ces étapes et en comprenant les modèles d’allocation de mémoire, vous gérerez plus efficacement l’utilisation de la mémoire dans votre instance de base de données Aurora MySQL et éviterez les problèmes de performances potentiels dus à la pression de la mémoire.
# Résolution des problèmes de mémoire insuffisante pour les bases de données Aurora MySQL
Le paramètre de niveau instance Aurora MySQL `aurora_oom_response` peut autoriser l’instance de base de données à surveiller la mémoire système et à estimer la mémoire utilisée par différentes déclarations et connexions. Si le système manque de mémoire, il peut effectuer une série d’actions pour tenter de libérer cette mémoire. L’objectif est d’éviter le redémarrage de la base de données en raison de problèmes de mémoire insuffisante. Ce paramètre de niveau instance accepte une chaîne d’actions (séparées par des virgules) qu’une instance de base de données doit effectuer lorsque sa mémoire est faible. Le paramètre `aurora_oom_response` est pris en charge pour Aurora MySQL versions 2 et 3.
Les valeurs suivantes, ainsi que leurs combinaisons, peuvent être utilisées pour le paramètre `aurora_oom_response`. Une chaîne vide signifie qu’aucune action n’est effectuée et revient à désactiver la fonctionnalité. La base de données peut donc faire l’objet de redémarrages en raison d’une mémoire insuffisante.
+ `decline` : refuse les nouvelles requêtes une fois que l’instance de base de données manque de mémoire.
+ `kill_connect` : ferme les connexions de base de données qui consomment une grande quantité de mémoire et met fin aux transactions en cours et aux instructions DDL (Data Definition Language). Cette réponse n’est pas prise en charge pour Aurora MySQL version 2.
Pour plus d’informations, consultez [KILL Statement](https://dev.mysql.com/doc/refman/8.0/en/kill.html) dans la documentation MySQL.
+ `kill_query` : arrête les requêtes dans l’ordre décroissant de leur consommation de mémoire jusqu’à ce que la mémoire de l’instance passe au-dessus du seuil bas. Les instructions DDL ne sont pas arrêtées.
Pour plus d’informations, consultez [KILL Statement](https://dev.mysql.com/doc/refman/8.0/en/kill.html) dans la documentation MySQL.
+ `print` : imprime uniquement les requêtes qui consomment une grande quantité de mémoire.
+ `tune` : affine les caches de table interne pour restituer de la mémoire au système. Aurora MySQL réduit la mémoire utilisée pour les caches tels que `table_open_cache` et `table_definition_cache` dans des conditions de faible mémoire. Finalement, Aurora MySQL rétablit l’utilisation de la mémoire à des conditions normales lorsque le système n’est plus à court de mémoire.
Pour plus d’informations, consultez [table\$1open\$1cache](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_table_open_cache) et [table\$1definition\$1cache](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_table_definition_cache) dans la documentation MySQL.
+ `tune_buffer_pool` : diminue la taille du pool de tampons afin de libérer de la mémoire et de la rendre disponible pour que le serveur de base de données puisse traiter les connexions. Cette réponse est prise en charge pour Aurora MySQL versions 3.06 et ultérieures.
Vous devez associer `tune_buffer_pool` avec `kill_query` ou `kill_connect` dans la valeur du paramètre `aurora_oom_response`. Dans le cas contraire, le redimensionnement du pool de tampons ne se produira pas, même si vous incluez `tune_buffer_pool` dans la valeur du paramètre.
Dans les versions d’Aurora MySQL antérieures à 3.06, pour les classes d’instance de base de données dont la mémoire est inférieure ou égale à 4 Gio, lorsque l’instance est soumise à une pression de mémoire, les actions par défaut incluent `print`, `tune`, `decline` et `kill_query`. Pour les classes d’instance de base de données dont la mémoire est supérieure à 4 Gio, la valeur du paramètre est vide par défaut (désactivé).
Dans Aurora MySQL 3.06 et versions ultérieures, pour les classes d’instance de base de données dont la mémoire est inférieure ou égale à 4 Gio, Aurora MySQL ferme également les connexions les plus gourmandes en mémoire (`kill_connect`). Pour les classes d’instance de base de données dont la mémoire est supérieure à 4 Gio, la valeur du paramètre par défaut est `print`.
Dans Aurora MySQL 3.09 et versions ultérieures, pour les classes d’instance de base de données dont la mémoire est supérieure à 4 Gio, la valeur du paramètre par défaut est `print,decline,kill_connect`.
Si vous rencontrez fréquemment des problèmes de mémoire insuffisante, l’utilisation de la mémoire peut être surveillée à l’aide de [tableaux récapitulatifs de la mémoire](https://dev.mysql.com/doc/refman/8.3/en/performance-schema-memory-summary-tables.html) lorsque `performance_schema` est activé.
Pour les métriques Amazon CloudWatch relatives à un problème de mémoire insuffisante, consultez [Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). Pour les variables d’état globales liées à une mémoire insuffisante, consultez [Variables d’état globales Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md).
# Journalisation pour les bases de données Aurora MySQL
Les journaux Aurora MySQL fournissent des informations essentielles sur l’activité et les erreurs de base de données. En les activant, vous pouvez identifier et résoudre les problèmes, comprendre les performances de la base de données et en auditer l’activité. Nous vous recommandons d’activer ces journaux pour toutes vos instances de base de données Aurora MySQL afin de garantir des performances et une disponibilité optimales des bases de données. Les types de journaux suivants peuvent être activés. Chaque journal contient des informations spécifiques qui peuvent contribuer à identifier des impacts sur le traitement de la base de données.
+ Erreur : Aurora MySQL écrit dans le journal d’erreurs uniquement au moment du démarrage, de l’arrêt et lorsqu’une erreur survient. Une instance de base de données peut fonctionner pendant des heures ou des jours sans qu’aucune nouvelle entrée soit écrite dans le journal des erreurs. Si aucune entrée récente ne figure, cela signifie que le serveur n’a pas rencontré d’erreur justifiant une entrée de journal. La journalisation des erreurs est activée par défaut. Pour plus d’informations, consultez [Journaux des erreurs Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Errorlog).
+ Général : le journal général fournit des informations détaillées sur l’activité de la base de données, y compris toutes les instructions SQL exécutées par le moteur de base de données. Pour plus d’informations sur l’activation de la journalisation générale et la définition des paramètres de journalisation, consultez [Journal des requêtes lentes et journal général Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Generallog) et [Journal des requêtes générales](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) dans la documentation MySQL.
**Note**
Les journaux généraux peuvent devenir très volumineux et consommer de l’espace de stockage. Pour plus d’informations, consultez [Renouvellement et rétention des journaux pour Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.AMS.LogFileSize.retention).
+ Requêtes lentes : le journal des requêtes lentes se compose des instructions SQL qui ont pris plus de [long\$1query\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_long_query_time) secondes pour s’exécuter et qui nécessitent l’examen d’au moins [min\$1examined\$1row\$1limit](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_min_examined_row_limit) lignes. Vous pouvez utiliser le journal des requêtes lentes pour rechercher les requêtes dont l’exécution prend du temps et qui sont donc de bonnes candidates pour l’optimisation.
La valeur par défaut de `long_query_time` est 10 secondes. Nous vous recommandons de commencer par une valeur élevée pour identifier les requêtes les plus lentes, puis de la réduire petit à petit pour optimiser le réglage.
Vous pouvez également utiliser des paramètres connexes, tels que `log_slow_admin_statements` et `log_queries_not_using_indexes`. Comparez `rows_examined` à `rows_returned`. Si la valeur de `rows_examined` est bien supérieure à `rows_returned`, ces requêtes peuvent potentiellement être bloquantes.
Dans Aurora MySQL version 3, vous pouvez activer `log_slow_extra` pour obtenir plus de détails. Pour plus d’informations, consultez [Contenu du journal des requêtes lentes](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html#slow-query-log-contents) dans la documentation MySQL. Vous pouvez également modifier `long_query_time` au niveau de la session pour déboguer l’exécution des requêtes de manière interactive, ce qui est particulièrement utile si `log_slow_extra` est activé globalement.
Pour plus d’informations sur l’activation de la journalisation des requêtes lentes et la définition des paramètres de journalisation, consultez [Journal des requêtes lentes et journal général Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Generallog) et [Journal des requêtes lentes](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) dans la documentation MySQL.
+ Audit ; le journal d’audit surveille et enregistre l’activité de la base de données. La journalisation d’audit pour Aurora MySQL se nomme « audit avancé ». Pour activer l’audit avancé, vous devez définie certains paramètres de cluster de bases de données. Pour plus d’informations, consultez [Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
+ Binaire : le journal binaire (binlog) contient les événements qui décrivent les modifications apportées à la base de données, telles que les opérations de création de tables ou de modification des données des tables. Il contient également les événements relatifs aux instructions susceptibles d’apporter des modifications (par exemple, une instruction [DELETE](https://dev.mysql.com/doc/refman/8.0/en/delete.html) ne correspondant à aucune ligne), à moins que la journalisation basée sur les lignes ne soit utilisée. Le journal binaire contient également des informations sur le temps nécessaire à chaque instruction pour mettre à jour les données.
L’exécution d’un serveur lorsque la journalisation binaire est activée ralentit légèrement les performances. Toutefois, les avantages du journal binaire, qui vous permet de configurer la réplication et d’effectuer des opérations de restauration, compensent généralement cette baisse mineure des performances.
**Note**
Aurora MySQL ne nécessite pas de journalisation binaire pour les opérations de restauration.
Pour plus d’informations sur l’activation de la journalisation binaire et la définition du format de journal binaire, consultez [Configuration d'Aurora MySQL les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md) et [Journal binaire](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) dans la documentation MySQL.
Vous pouvez publier les journaux d’erreurs, les journaux généraux, les journaux de requêtes lentes et les journaux d’audit dans Amazon CloudWatch Logs. Pour plus d’informations, consultez [Publication des journaux de base de données dans Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md).
[pt-query-digest](https://docs.percona.com/percona-toolkit/pt-query-digest.html) est un autre outil utile pour résumer les journaux de requêtes lentes, les journaux généraux et les journaux binaires.
# Résolution des problèmes de connexion aux bases de données Aurora MySQL
Garantir une connectivité fiable entre vos applications et votre instance de base de données RDS est crucial pour le bon fonctionnement de vos charges de travail. Cependant, les problèmes de connectivité peuvent survenir en raison de divers facteurs, tels que les configurations réseau, les problèmes d’authentification ou les contraintes de ressources. Ce guide vise à fournir une approche complète pour résoudre les problèmes de connectivité rencontrés avec Aurora MySQL.
**Contents**
+ [
## Identification des problèmes de connectivité des bases de données avec Aurora MySQL
](#mysql-dbconn-identify)
+ [
## Collecte de données sur les problèmes de connectivité pour Aurora MySQL
](#mysql-dbconn-gather)
+ [
## Surveillance des connexions aux bases de données pour Aurora MySQL
](#mysql-dbconn-monitor)
+ [
### Surveillance supplémentaire pour Aurora MySQL
](#mysql-dbconn-monitor-ams)
+ [
## Codes d’erreur de connectivité pour Aurora MySQL
](#mysql-dbconn-errors)
+ [
## Recommandations de réglage des paramètres pour Aurora MySQL
](#mysql-dbconn-params)
+ [
## Exemples de résolution des problèmes de connexion aux bases de données pour Aurora MySQL
](#mysql-dbconn-examples)
+ [
### Exemple 1 : résolution des problèmes liés aux tentatives de connexion infructueuses
](#mysql-dbconn-example1)
+ [
### Exemple 2 : résolution des problèmes de déconnexion anormale des clients
](#mysql-dbconn-example2)
+ [
### Exemple 3 : résolution des problèmes liés à l'échec des tentatives de connexion IAM
](#mysql-dbconn-example3)
## Identification des problèmes de connectivité des bases de données avec Aurora MySQL
L’identification de la catégorie spécifique du problème de connectivité permet de déterminer les causes potentielles et d’orienter le processus de résolution des problèmes. Chaque catégorie peut nécessiter des approches et des techniques différentes pour le diagnostic et la résolution. Les problèmes de connectivité des bases de données peuvent généralement être classés dans les catégories suivantes.
**Erreurs et exceptions de connexion**
Des erreurs et exceptions de connexion peuvent se produire pour diverses raisons, telles qu’une chaîne de connexion incorrecte, un échec d’authentification, une interruption du réseau ou un problème sur le serveur de base de données. Parmi les causes figurent une configuration erronée des paramètres de connexion, des identifiants non valides, une défaillance du réseau ou un crash/redémarrage du serveur de base de données. Les groupes de sécurité mal configurés, les paramètres du cloud privé virtuel (VPC), les listes de contrôle d'accès réseau ACLs () et les tables de routage associées aux sous-réseaux peuvent également entraîner des problèmes de connexion.
**Limite de connexion atteinte**
Ce problème survient lorsque le nombre de connexions simultanées au serveur de base de données dépasse la limite maximale autorisée. Les serveurs de bases de données sont généralement soumis à une limite maximale de connexions configurable, définie par le paramètre max\$1connections dans les groupes de paramètres de cluster et d’instance. En imposant une limite de connexion, le serveur de base de données s’assure qu’il dispose de suffisamment de ressources (par exemple, mémoire, CPU et descripteurs de fichiers) pour gérer efficacement les connexions existantes et fournir des performances acceptables. Parmi les causes citons des fuites de connexion dans l’application, un regroupement de connexions inefficace ou une augmentation inattendue du nombre de demandes de connexion.
**Délai d’expiration de connexion**
Les délais d’expiration de connexion se produisent lorsque l’application cliente ne parvient pas à établir une connexion avec le serveur de base de données dans le délai imparti. Parmi les causes les plus fréquentes figurent des dysfonctionnements réseau, une saturation du serveur, des règles de pare-feu ou une configuration incorrecte des paramètres de connexion.
**Délai d’expiration de connexion inactive**
Les connexions inactives qui restent inactives pendant une période prolongée peuvent être fermées automatiquement par le serveur de base de données pour économiser les ressources. Ce délai d’expiration est généralement configurable à l’aide de `wait_timeout` et `interactive_timeout parameters`. Il doit être ajusté en fonction des modèles d’utilisation des connexions de l’application. Les causes peuvent être liées à une logique d’application qui laisse des connexions inactives trop longtemps, ou à une gestion inadéquate des connexions.
**Déconnexion intermittente des connexions existantes**
Cette catégorie d’erreurs fait référence à un scénario dans lequel les connexions établies entre une application cliente et la base de données sont interrompues de façon inattendue ou déconnectées à intervalles irréguliers, alors qu’elles sont actives et en cours d’utilisation. Ces déconnexions se produisent de manière intermittente, c’est-à-dire à des intervalles irréguliers et de façon non prévisible. Voici les causes possibles :
+ Problèmes liés au serveur de base de données, tels que les redémarrages ou les basculements
+ Mauvaise gestion des connexions d’applications
+ Problèmes d’équilibrage de charge et de proxy
+ Instabilité réseau
+ Problèmes liés aux composants tiers ou aux intergiciels impliqués dans le chemin de connexion
+ Délais d’expiration d’exécution de requête
+ Contraintes de ressources côté serveur ou côté client
Il est essentiel d’identifier la cause première à l’aide d’une surveillance, d’une journalisation et d’une analyse approfondies. La mise en œuvre de mécanismes adaptés de gestion des erreurs, de regroupement des connexions et de nouvelles tentatives peut contribuer à réduire l’impact de ces déconnexions intermittentes sur les fonctionnalités de l’application et sur l’expérience utilisateur.
## Collecte de données sur les problèmes de connectivité pour Aurora MySQL
La collecte de données complètes relatives aux composants de l’application, de la base de données, du réseau et de l’infrastructure est essentielle pour résoudre efficacement les problèmes de connectivité entre une application et une base de données Aurora MySQL. En collectant les journaux, les configurations et les données de diagnostic pertinents, vous obtenez des informations précieuses qui peuvent vous aider à identifier la cause première des problèmes de connectivité et à vous guider vers une résolution appropriée.
Les journaux et les configurations réseau, tels que les règles des groupes de sécurité, les paramètres de VPC et les tables de routage, sont essentiels pour identifier d’éventuels goulots d’étranglement ou des erreurs de configuration réseau susceptibles d’empêcher la connexion entre l’application et la base de données. En analysant ces composants réseau, vous pouvez vous assurer que les ports nécessaires sont ouverts, que les adresses IP sont autorisées et que les configurations de routage sont correctement configurées.
**Horodatages**
Enregistrez les horodatages exacts lorsque les problèmes de connectivité surviennent. Cette approche permet d’identifier des modèles ou de corréler les problèmes avec d’autres événements ou activités.
**Journaux du moteur de base de données**
Outre les journaux généraux de la base de données, consultez les journaux du moteur de base de données (par exemple, le journal d’erreurs MySQL et le journal des requêtes lentes) pour obtenir toute information pertinente ou erreur susceptible d’être liée aux problèmes de connectivité intermittents. Pour plus d’informations, consultez [Journalisation pour les bases de données Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
**Journaux d’applications clientes**
Collectez des journaux détaillés à partir des applications clientes qui se connectent à la base de données. Les journaux d’application offrent une visibilité sur les tentatives de connexion, les erreurs et toute autre information pertinente du point de vue de l’application, susceptibles de révéler des problèmes liés aux chaînes de connexion, aux informations d’identification d’authentification ou à la gestion des connexions dans l’application.
Les journaux de base de données, quant à eux, fournissent des informations sur les erreurs liées à la base de données, la lenteur des requêtes ou les événements susceptibles de contribuer aux problèmes de connectivité. Pour plus d’informations, consultez [Journalisation pour les bases de données Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
**Variables d’environnement du client**
Vérifiez si des variables d'environnement ou des paramètres de configuration côté client peuvent affecter la connexion à la base de données, tels que les paramètres du proxy, SSL/TLS les paramètres ou toute autre variable pertinente.
**Versions de la bibliothèque cliente**
Assurez-vous que le client utilise les dernières versions de tous les pilotes de base de données, bibliothèques ou frameworks utilisés pour la connectivité aux bases de données. Les versions obsolètes peuvent présenter des problèmes connus ou des problèmes de compatibilité.
**Capture réseau du client**
Effectuez une capture réseau côté client à l’aide d’un outil tel que Wireshark ou `tcpdump` lorsque des problèmes de connectivité surviennent. Cette opération peut contribuer à identifier les problèmes ou irrégularités liés au réseau côté client.
**Topologie réseau du client**
Il est important de bien comprendre la topologie réseau du client, notamment la présence éventuelle de pare-feux, d’équilibreurs de charge ou d’autres composants (tels que RDS Proxy ou Proxy SQL) qui se connectent à la base de données à la place du client.
**Paramètres du système d’exploitation client**
Vérifiez les paramètres du système d’exploitation du client susceptibles d’affecter la connectivité réseau, tels que les règles de pare-feu, les paramètres de l’adaptateur réseau et tout autre paramètre pertinent.
**Configuration du regroupement de connexions**
Si vous utilisez un mécanisme de regroupement de connexions dans votre application, passez en revue les paramètres de configuration et surveillez les métriques du regroupement (par exemple, les connexions actives, les connexions inactives et les délais d’expiration des connexions) pour vous assurer que le groupe fonctionne correctement. Vérifiez également les paramètres du regroupement, tels que la taille maximale du groupe, la taille minimale du groupe et les paramètres de validation de connexion, pour vous assurer qu’ils sont correctement configurés.
**Chaîne de connexion**
La chaîne de connexion inclut généralement des paramètres tels que le nom d’hôte ou de point de terminaison, le numéro de port, le nom de la base de données et les informations d’identification d’authentification. L’analyse de la chaîne de connexion permet d’identifier les erreurs de configuration potentielles ou les paramètres incorrects susceptibles de provoquer des problèmes de connectivité. Par exemple, un nom d’hôte ou un numéro de port incorrect peut empêcher le client d’accéder à l’instance de base de données, tandis que des informations d’identification d’authentification non valides peuvent entraîner des échecs d’authentification et des rejets de connexion. En outre, la chaîne de connexion peut révéler des problèmes liés au regroupement des connexions, aux délais d’expiration ou à d’autres paramètres spécifiques à la connexion susceptibles de contribuer aux problèmes de connectivité. La fourniture de la chaîne de connexion complète utilisée par l’application cliente permet d’identifier les erreurs de configuration sur le client.
**Métriques de base de données**
Surveillez les indicateurs de base de données tels que l'utilisation du processeur, de la mémoire et du disque I/O lorsque des problèmes de connectivité surviennent. Elles permettent de déterminer si l’instance de base de données est confrontée à des problèmes de contention des ressources ou de performances.
**Version du moteur de base de données**
Notez la version du moteur de base de données Aurora MySQL. AWS publie régulièrement des mises à jour visant à résoudre des problèmes connus, corriger des failles de sécurité et améliorer les performances. Par conséquent, nous vous recommandons vivement de passer aux dernières versions disponibles, car ces mises à jour incluent souvent des corrections de bogues et des améliorations spécifiquement liées à la connectivité, aux performances et à la stabilité. Fournir les informations de version de la base de données, ainsi que les autres informations collectées, peut aider Support à diagnostiquer et à résoudre efficacement les problèmes de connectivité.
**Métriques de réseau**
Collectez des métriques de réseau tels que la latence, la perte de paquets et le débit lorsque des problèmes de connectivité surviennent. Des outils tels que `ping`, `traceroute` et les outils de surveillance réseau permettent de recueillir ces données.
**Détails sur la source et le client**
Déterminez les adresses IP des serveurs d’applications, des équilibreurs de charge ou de tout autre composant qui initie les connexions à la base de données. Il peut s’agir d’une seule adresse IP ou d’une plage d’adresses IP (notation CIDR). Si la source est une EC2 instance Amazon, il est également utile de vérifier le type d'instance, la zone de disponibilité, l'ID de sous-réseau et les groupes de sécurité associés à l'instance, ainsi que les détails de l'interface réseau tels que l'adresse IP privée et l'adresse IP publique.
En analysant minutieusement les données collectées, vous pouvez identifier les erreurs de configuration, les contraintes de ressources, les perturbations du réseau ou les autres problèmes sous-jacents à l’origine des problèmes de connectivité intermittents ou persistants. Ces informations vous permettent de prendre des mesures ciblées, telles que l’ajustement des configurations, la résolution des problèmes de réseau ou la gestion des connexions au niveau de l’application.
## Surveillance des connexions aux bases de données pour Aurora MySQL
Pour surveiller et résoudre les problèmes de connectivité, vous pouvez utiliser les métriques et fonctionnalités suivantes.
**CloudWatch métriques**
+ `CPUUtilization` : l’utilisation élevée de l’UC sur l’instance de base de données peut ralentir l’exécution des requêtes, ce qui peut entraîner des délais d’expiration ou des rejets de connexion.
+ `DatabaseConnections` : surveille le nombre de connexions actives à l’instance de base de données. Un nombre élevé de connexions proche de la valeur maximale configurée peut indiquer des problèmes de connectivité potentiels ou une saturation du regroupement de connexions.
+ `FreeableMemory` : la faible quantité de mémoire disponible peut entraîner des problèmes de performances et de connectivité en raison de contraintes de ressources.
+ `NetworkReceiveThroughput` et `NetworkTransmitThroughput` : des pics ou des baisses inhabituels du débit réseau peuvent indiquer des problèmes de connectivité ou des goulots d’étranglement du réseau.
**Métriques de Performance Insights**
Pour résoudre les problèmes de connectivité dans Aurora MySQL à l’aide de Performance Insights, analysez les métriques de base de données suivantes :
+ Aborted\$1clients
+ Aborted\$1connects
+ Connexions
+ max\$1connections
+ Threads\$1connected
+ Threads\$1created
+ Threads\$1running
Ces métriques peuvent vous aider à identifier les goulots d’étranglement de connexion, détecter les problèmes de réseau ou d’authentification, optimiser le regroupement des connexions et garantir une gestion efficace des threads. Pour plus d’informations, consultez [Compteurs Performance Insights pour Aurora MySQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.Aurora_MySQL).
**Fonctionnalité de Performance Insights**
+ **Charge de la base de données** : visualisez la charge de la base de données au fil du temps et corrélez-la aux problèmes de connectivité ou à la dégradation des performances.
+ **Statistiques SQL** : analysez les statistiques SQL pour identifier les requêtes ou les opérations de base de données inefficaces susceptibles d’entraîner des problèmes de connectivité.
+ **Requêtes principales** : identifiez et analysez les requêtes les plus gourmandes en ressources, en vue d’identifier les problèmes de performance potentiels ou les requêtes de longue durée susceptibles de provoquer des problèmes de connectivité.
En surveillant ces métriques et en tirant parti de Performance Insights, vous pouvez acquérir une meilleure visibilité sur les performances de l’instance de base de données, l’utilisation des ressources et les goulots d’étranglement potentiels susceptibles de causer des problèmes de connectivité. Par exemple :
+ Un niveau `DatabaseConnections` proche de la limite maximale peut indiquer une saturation du regroupement de connexions ou une mauvaise gestion des connexions, ce qui peut entraîner des problèmes de connectivité.
+ Un niveau `CPUUtilization` élevé ou `FreeableMemory` faible peut indiquer des contraintes de ressources, susceptibles de ralentir l’exécution des requêtes et de provoquer des délais d’expiration ou des rejets de connexion.
+ L’analyse des **Requêtes principales** et des **Statistiques SQL** permet d’identifier les requêtes inefficaces ou gourmandes en ressources susceptibles de contribuer aux problèmes de connectivité.
En outre, la surveillance CloudWatch des journaux et la configuration d'alarmes peuvent vous aider à identifier les problèmes de connectivité et à y répondre de manière proactive avant qu'ils ne s'aggravent.
Il est important de noter que si ces métriques et outils peuvent fournir des informations précieuses, ils doivent être utilisés conjointement avec d’autres processus de résolution des problèmes. En examinant également les configurations réseau, les règles des groupes de sécurité et la gestion des connexions au niveau de l’application, vous pouvez diagnostiquer et résoudre de manière exhaustive les problèmes de connectivité liés aux instances de base de données Aurora MySQL.
### Surveillance supplémentaire pour Aurora MySQL
**CloudWatch métriques**
+ `AbortedClients` : suit le nombre de connexions client qui n’ont pas été fermées correctement.
+ `AuroraSlowConnectionHandleCount` : suit le nombre d’opérations de gestion des connexions lentes, en indiquant les problèmes de connectivité potentiels ou les goulots d’étranglement liés aux performances.
+ `AuroraSlowHandshakeCount` : indique le nombre d’opérations d’établissement de liaison lentes, également susceptible de révéler des problèmes de connectivité.
+ `ConnectionAttempts` : indique le nombre de tentatives de connexion effectuées à l’instance de base de données Aurora MySQL.
**Variables d’état globales**
`Aurora_external_connection_count` : indique le nombre de connexions de base de données à l’instance de base de données, à l’exclusion des connexions au service RDS utilisées pour la surveillance de l’état de la base de données.
En surveillant ces métriques et ces variables d’état globales, vous pouvez acquérir une meilleure visibilité sur les modèles de connexion, les erreurs et les goulots d’étranglement potentiels susceptibles de provoquer des problèmes de connectivité avec votre instance Amazon Aurora MySQL.
Par exemple, un nombre élevé de `AbortedClients` ou `AuroraSlowConnectionHandleCount` peut indiquer des problèmes de connectivité.
En outre, la configuration d' CloudWatch alarmes et de notifications peut vous aider à identifier les problèmes de connectivité et à y répondre de manière proactive avant qu'ils ne s'aggravent et n'affectent les performances de votre application.
## Codes d’erreur de connectivité pour Aurora MySQL
Voici quelques erreurs de connectivité courantes concernant les bases de données Aurora MySQL, ainsi que leurs codes d’erreur et leurs explications.
**Error Code 1040: Too many connections**
Cette erreur se produit lorsque le client essaie d’établir un nombre de connexions supérieur au maximum autorisé par le serveur de base de données. Les causes possibles sont notamment les suivantes :
+ Mauvaise configuration du regroupement de connexions : si vous utilisez un mécanisme de regroupement de connexions, assurez-vous que la taille maximale de ce dernier n’est pas trop élevée et que les connexions sont correctement rétablies dans le regroupement.
+ Configuration de l’instance de base de données : vérifiez le paramètre de connexions maximales autorisées pour l’instance de base de données et ajustez-le si nécessaire en définissant le paramètre `max_connections`.
+ Haute simultanéité : la connexion simultanée d’un grand nombre de clients ou d’applications à la base de données peut entraîner l’atteinte du seuil maximal de connexions autorisées.
**Error Code 1045: Access denied for user ’...’@’...’ (using password: YES/NO)**
Cette erreur indique un échec d’authentification lors de la tentative de connexion à la base de données. Les causes possibles sont notamment les suivantes :
+ Compatibilité des plug-ins d’authentification : vérifiez si le plug-in d’authentification utilisé par le client est compatible avec le mécanisme d’authentification du serveur de base de données.
+ Nom d’utilisateur ou mot de passe incorrect : vérifiez que le nom d’utilisateur et le mot de passe utilisés dans la chaîne de connexion ou le mécanisme d’authentification sont corrects.
+ Autorisations utilisateur : assurez-vous que l’utilisateur dispose des autorisations nécessaires pour se connecter à l’instance de base de données depuis l’hôte ou le réseau spécifié.
**Error Code 1049: Unknown database ’...’**
Cette erreur indique que le client tente de se connecter à une base de données qui n’existe pas sur le serveur. Les causes possibles sont notamment les suivantes :
+ Base de données non créée : assurez-vous que la base de données spécifiée a été créée sur le serveur de base de données.
+ Nom de base de données incorrect : vérifiez l’exactitude du nom de base de données utilisé dans la chaîne de connexion ou dans la requête.
+ Autorisations utilisateur : vérifiez que l’utilisateur dispose des autorisations nécessaires pour accéder à la base de données spécifiée.
**Error Code 1153: Got a packet bigger than ’max\$1allowed\$1packet’ bytes**
Cette erreur se produit lorsque le client tente d’envoyer ou de recevoir des données qui dépassent la taille de paquet maximale autorisée par le serveur de base de données. Les causes possibles sont notamment les suivantes :
+ Ensembles de requêtes ou de résultats volumineux : si vous exécutez des requêtes impliquant de grandes quantités de données, la limite de taille des paquets peut être dépassée.
+ Paramètres de taille de paquet mal configurés : vérifiez le paramètre `max_allowed_packet` sur le serveur de base de données et ajustez-le si nécessaire.
+ Problèmes de configuration réseau : assurez-vous que la configuration réseau (par exemple, la taille MTU) autorise les tailles de paquets requises.
**Error Code 1226: User ’...’ has exceeded the ’max\$1user\$1connections’ resource (current value: ...)**
Cette erreur indique que l’utilisateur a dépassé le nombre maximal de connexions simultanées autorisées par le serveur de base de données. Les causes possibles sont notamment les suivantes :
+ Mauvaise configuration du regroupement de connexions : si vous utilisez un mécanisme de regroupement de connexions, assurez-vous que la taille maximale de ce dernier n’est pas configurée au-delà de la limite de connexions autorisée pour l’utilisateur.
+ Configuration de l’instance de base de données : vérifiez le paramètre `max_user_connections` pour l’instance de base de données et ajustez-le si nécessaire.
+ Haute simultanéité : si plusieurs clients ou applications se connectent simultanément à la base de données en utilisant le même utilisateur, la limite de connexions spécifique à cet utilisateur peut être atteinte.
**Error Code 2003: Can’t connect to MySQL server on ’...’ (10061)**
Cette erreur se produit généralement lorsque le client ne parvient pas à établir une TCP/IP connexion avec le serveur de base de données. Elle peut être due à divers problèmes, notamment :
+ État de l’instance de base de données : assurez-vous que l’instance de base de données présente l’état `available` et qu’elle ne fait l’objet d’aucune opération de maintenance ou de sauvegarde.
+ Règles de pare-feu : vérifiez si des pare-feux (système d’exploitation, réseau ou groupe de sécurité) bloquent la connexion sur le port spécifié (généralement 3306 pour MySQL).
+ Nom d’hôte ou point de terminaison incorrect : assurez-vous que le nom d’hôte ou le point de terminaison utilisé dans la chaîne de connexion est correct et correspond à l’instance de base de données.
+ Problèmes de connectivité réseau : vérifiez que l’ordinateur client peut accéder à l’instance de base de données via le réseau. Vérifiez l’existence d’éventuelles pannes réseau, de problèmes de routage ou de mauvaises configurations de VPC ou de sous-réseau.
**Error Code 2005: Unknown MySQL server host ’...’ (11001)**
Cette erreur se produit lorsque le client ne parvient pas à convertir le nom d’hôte ou le point de terminaison du serveur de base de données en adresse IP. Les causes possibles sont notamment les suivantes :
+ Problèmes de résolution DNS : vérifiez que l’ordinateur client peut résoudre correctement le nom d’hôte à l’aide du DNS. Vérifiez les paramètres DNS, le cache DNS et essayez d’utiliser l’adresse IP au lieu du nom d’hôte.
+ Nom d’hôte ou point de terminaison incorrect : vérifiez l’exactitude du nom d’hôte ou du point de terminaison utilisé dans la chaîne de connexion.
+ Problèmes de configuration réseau : assurez-vous que la configuration réseau du client (par exemple, VPC, sous-réseau et tables de routage) autorise la résolution DNS et la connectivité à l’instance de base de données.
**Error Code 2026: SSL connection error**
Cette erreur se produit en cas de problème de SSL/TLS configuration ou de validation du certificat lors de la tentative de connexion. Les causes possibles sont notamment les suivantes :
+ Expiration du certificat — Vérifiez si le SSL/TLS certificat utilisé par le serveur a expiré et doit être renouvelé.
+ Problèmes de validation des certificats : vérifiez que le client est en mesure de valider correctement le SSL/TLS certificat du serveur et que le certificat est fiable.
+ Problèmes de configuration réseau — Assurez-vous que la configuration réseau autorise les SSL/TLS connexions et ne bloque pas ou n'interfère pas avec le processus de SSL/TLS prise de contact.
+ SSL/TLS configuration mismatch – Make sure that the SSL/TLSles paramètres (par exemple, les suites de chiffrement et les versions de protocole) du client et du serveur sont compatibles.
La compréhension des explications détaillées et des causes possibles de chaque code d’erreur permet de mieux diagnostiquer et corriger les problèmes de connectivité rencontrés avec les bases de données Aurora MySQL.
## Recommandations de réglage des paramètres pour Aurora MySQL
**Nombre maximal de connexions**
Le réglage de ces paramètres permet d’éviter les problèmes de connexion provoqués par l’atteinte de la limite maximale de connexions autorisées. Assurez-vous que ces valeurs sont définies de manière appropriée en fonction des exigences de simultanéité et des contraintes de ressources de votre application.
+ `max_connections` : ce paramètre spécifie le nombre maximum de connexions simultanées autorisées à l’instance de base de données.
+ `max_user_connections` : ce paramètre peut être spécifié lors de la création et de la modification d’un utilisateur. Il définit le nombre maximal de connexions simultanées autorisées pour un compte utilisateur spécifique.
**Taille du tampon réseau**
L’augmentation de ces valeurs peut améliorer les performances du réseau, en particulier pour les charges de travail impliquant des transferts de données ou des jeux de résultats importants. Faites néanmoins attention, car l’augmentation de la taille des tampons entraîne une consommation mémoire plus importante.
+ `net_buffer_length` : ce paramètre définit la taille initiale de la connexion client et des tampons de résultats, en équilibrant l’utilisation de la mémoire avec les performances des requêtes.
+ `max_allowed_packet` : ce paramètre spécifie la taille maximale d’un seul paquet réseau qui peut être envoyé ou reçu par l’instance de base de données.
**Compression réseau (côté client)**
L’activation de la compression réseau peut réduire l’utilisation de la bande passante du réseau, mais elle peut augmenter la charge de l’UC du côté client et du côté serveur.
+ `compress`— Ce paramètre active ou désactive la compression réseau pour les client/server communications.
+ `compress_protocol` : ce paramètre spécifie le protocole de compression à utiliser pour les communications réseau.
**Réglage des performances réseau**
Le réglage de ces délais permet de mieux gérer les connexions inactives et d’éviter une surcharge des ressources, mais attention : des valeurs trop faibles peuvent entraîner des déconnexions prématurées.
+ `interactive_timeout` : ce paramètre indique le nombre de secondes pendant lesquelles le serveur attend une activité sur une connexion interactive avant de la fermer.
+ `wait_timeout` : ce paramètre détermine le nombre de secondes pendant lesquelles le serveur attend une activité sur une connexion non interactive avant de la fermer.
**Paramètres de délai d’expiration réseau**
Le réglage de ces délais permet de résoudre les problèmes liés à la lenteur ou à l’absence de réponse des connexions. Soyez toutefois prudent : des valeurs trop faibles peuvent provoquer des échecs de connexion prématurés.
+ `net_read_timeout` : ce paramètre indique le nombre de secondes à attendre pour recevoir davantage de données d’une connexion avant de mettre fin à l’opération de lecture.
+ `net_write_timeout` : ce paramètre détermine le nombre de secondes à attendre avant qu’un bloc soit écrit sur une connexion avant de mettre fin à l’opération d’écriture.
## Exemples de résolution des problèmes de connexion aux bases de données pour Aurora MySQL
Les exemples suivants montrent comment identifier et résoudre les problèmes de connexion aux bases de données Aurora MySQL.
### Exemple 1 : résolution des problèmes liés aux tentatives de connexion infructueuses
Les tentatives de connexion peuvent échouer pour plusieurs raisons, notamment les échecs d'authentification, les échecs de SSL/TLS prise de contact, la `max_connections` limite atteinte et les contraintes de ressources sur l'instance de base de données.
Vous pouvez suivre le nombre de connexions ayant échoué à partir de Performance Insights ou à l’aide de la commande suivante.
```
mysql> show global status like 'aborted_connects';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Aborted_connects | 7 |
+------------------+-------+
1 row in set (0.00 sec)
```
Si le nombre `Aborted_connects` augmente au fil du temps, il est possible que l’application rencontre des problèmes de connectivité intermittents.
Vous pouvez utiliser [Aurora Advanced Auditing](AuroraMySQL.Auditing.md) pour enregistrer les connexions et les déconnexions des clients. Vous pouvez le faire en définissant les paramètres suivants dans le groupe de paramètres de cluster de bases de données :
+ `server_audit_logging` = `1`
+ `server_audit_events` = `CONNECT`
Voici un extrait des journaux d’audit relatifs à un échec de connexion.
```
1728498527380921,auora-mysql-node1,user_1,172.31.49.222,147189,0,FAILED_CONNECT,,,1045
1728498527380940,auora-mysql-node1,user_1,172.31.49.222,147189,0,DISCONNECT,,,0
```
Où :
+ `1728498527380921` : l’horodatage de l’époque à laquelle l’échec de connexion s’est produit
+ `aurora-mysql-node1` : l’identifiant d’instance du nœud du cluster Aurora MySQL sur lequel la connexion a échoué
+ `user_1` : le nom de l’utilisateur de base de données pour lequel la connexion a échoué
+ `172.31.49.222` : l’adresse IP privée du client à partir duquel la connexion a été établie
+ `147189` : l’identifiant de connexion de l’échec de connexion
+ `FAILED_CONNECT` : indique que la connexion a échoué.
+ `1045` : le code de retour. Une valeur différente de zéro indique une erreur. Dans ce cas, `1045` correspond à un accès refusé.
Pour plus d’informations, consultez [Codes d’erreur serveur](https://dev.mysql.com/doc/mysql-errors/5.7/en/server-error-reference.html) et [Codes d’erreur client](https://dev.mysql.com/doc/mysql-errors/5.7/en/client-error-reference.html) dans la documentation MySQL.
Vous pouvez également examiner les journaux d’erreurs d’Aurora MySQL pour rechercher d’éventuels messages d’erreur associés, par exemple :
```
2024-10-09T19:26:59.310443Z 220 [Note] [MY-010926] [Server] Access denied for user 'user_1'@'172.31.49.222' (using password: YES) (sql_authentication.cc:1502)
```
### Exemple 2 : résolution des problèmes de déconnexion anormale des clients
Vous pouvez suivre le nombre de déconnexions anormales des clients à partir de Performance Insights ou à l’aide de la commande suivante.
```
mysql> show global status like 'aborted_clients';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Aborted_clients | 9 |
+-----------------+-------+
1 row in set (0.01 sec)
```
Si le nombre `Aborted_clients` augmente au fil du temps, cela signifie que l’application ne ferme pas correctement les connexions à la base de données. Si les connexions ne sont pas correctement fermées, cela peut entraîner des fuites de ressources et des problèmes de performances potentiels. Le fait de laisser des connexions ouvertes inutilement peut entraîner une consommation excessive de ressources système (mémoire, descripteurs de fichiers), pouvant à terme bloquer l’application ou le serveur, voire provoquer un redémarrage.
Vous pouvez utiliser la requête suivante pour identifier les comptes qui ne ferment pas correctement les connexions. Elle récupère le nom du compte utilisateur, l’hôte à partir duquel l’utilisateur se connecte, le nombre de connexions non fermées et le pourcentage de connexions non fermées.
```
SELECT
ess.user,
ess.host,
(a.total_connections - a.current_connections) - ess.count_star AS not_closed,
(((a.total_connections - a.current_connections) - ess.count_star) * 100) / (a.total_connections - a.current_connections) AS pct_not_closed
FROM
performance_schema.events_statements_summary_by_account_by_event_name AS ess
JOIN performance_schema.accounts AS a ON (ess.user = a.user AND ess.host = a.host)
WHERE
ess.event_name = 'statement/com/quit'
AND (a.total_connections - a.current_connections) > ess.count_star;
+----------+---------------+------------+----------------+
| user | host | not_closed | pct_not_closed |
+----------+---------------+------------+----------------+
| user1 | 172.31.49.222 | 1 | 33.3333 |
| user1 | 172.31.93.250 | 1024 | 12.1021 |
| user2 | 172.31.93.250 | 10 | 12.8551 |
+----------+---------------+------------+----------------+
3 rows in set (0.00 sec)
```
Après avoir identifié les comptes utilisateurs et les hôtes à partir desquels les connexions ne sont pas fermées, vous pouvez vérifier le code qui ne ferme pas les connexions correctement.
Par exemple, avec le connecteur MySQL en Python, utilisez la méthode `close()` de l’objet de connexion pour fermer les connexions. Voici un exemple de fonction qui établit une connexion à une base de données, exécute une requête et ferme la connexion :
```
import mysql.connector
def execute_query(query):
# Establish a connection to the database
connection = mysql.connector.connect(
host="your_host",
user="your_username",
password="your_password",
database="your_database"
)
try:
# Create a cursor object
cursor = connection.cursor()
# Execute the query
cursor.execute(query)
# Fetch and process the results
results = cursor.fetchall()
for row in results:
print(row)
finally:
# Close the cursor and connection
cursor.close()
connection.close()
```
Dans cet exemple, la méthode `connection.close()` est appelée dans le bloc `finally` pour s’assurer que la connexion est fermée, qu’une exception se produise ou non.
### Exemple 3 : résolution des problèmes liés à l'échec des tentatives de connexion IAM
La connectivité avec les utilisateurs d' AWS Identity and Access Management (IAM) peut échouer pour plusieurs raisons, notamment :
+ Configuration de la politique IAM incorrecte
+ Identifiants de sécurité expirés
+ Problèmes liés à la connectivité réseau
+ Incompatibilité des autorisations de base de données
Pour résoudre ces erreurs d'authentification, activez la fonctionnalité d'exportation des `iam-db-auth-error` journaux dans votre base de données Amazon Relational Database Service (RDS) ou Aurora. Cela vous permettra d'afficher les messages d'erreur d'authentification détaillés dans le groupe de CloudWatch journaux de votre cluster Amazon RDS ou Amazon Aurora.
Une fois activé, vous pouvez consulter ces journaux pour identifier et résoudre la cause spécifique de vos échecs d'authentification IAM.
Par exemple :
```
2025-09-22T12:02:30,806 [ERROR] Failed to authorize the connection request for user 'user_1' due to an internal IAM DB Auth error. (Status Code: 500, Error Code: InternalError)
```
and
```
2025-09-22T12:02:51,954 [ERROR] Failed to authenticate the connection request for user 'user_2' because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)
```
Pour obtenir des conseils de dépannage, reportez-vous au guide de dépannage [Aurora](UsingWithRDS.IAMDBAuth.Troubleshooting.md) pour l'authentification IAM DB.
# Résolution des problèmes de performance des requêtes pour les bases de données Aurora MySQL
MySQL permet de [contrôler l’optimiseur de requêtes](https://dev.mysql.com/doc/refman/8.0/en/controlling-optimizer.html) par le biais de variables système qui influent sur le mode d’évaluation des plans de requêtes, les optimisations remplaçables, les indices d’optimiseur et d’index, ainsi que le modèle de coût de l’optimiseur. Ces points de données peuvent être utiles non seulement pour comparer différents environnements MySQL, mais également pour comparer les plans d’exécution de requêtes précédents avec les plans d’exécution actuels, et pour comprendre l’exécution globale d’une requête MySQL à tout moment.
Les performances des requêtes dépendent de nombreux facteurs, notamment le plan d’exécution, le schéma et la taille de la table, les statistiques, les ressources, les index et la configuration des paramètres. L’ajustement des requêtes nécessite d’identifier les goulots d’étranglement et d’optimiser le chemin d’exécution.
+ Identifiez le plan d’exécution de la requête et vérifiez si cette dernière utilise les index appropriés. Vous pouvez optimiser votre requête en utilisant `EXPLAIN` et en examinant les détails de chaque plan.
+ Aurora MySQL version 3 (compatible avec MySQL 8.0 Community Edition) utilise une instruction `EXPLAIN ANALYZE`. L’instruction `EXPLAIN ANALYZE` est un outil de profilage qui indique où MySQL consacre du temps à votre requête, et pourquoi. Avec `EXPLAIN ANALYZE`, Aurora MySQL planifie, prépare et exécute la requête tout en comptant les lignes et en mesurant le temps passé à différents moments du plan d’exécution. Lorsque la requête est terminée, `EXPLAIN ANALYZE` imprime le plan et ses mesures au lieu du résultat de la requête.
+ Mettez à jour les statistiques de votre schéma à l’aide de l’instruction `ANALYZE`. L’optimiseur de requêtes peut parfois choisir des plans d’exécution inappropriés en raison de statistiques obsolètes. Cela peut nuire aux performances d’une requête en raison d’estimations de cardinalité inexactes à la fois pour les tables et les index. La colonne `last_update` de la table [innodb\$1table\$1stats](https://dev.mysql.com/doc/refman/8.0/en/innodb-persistent-stats.html#innodb-persistent-stats-tables) indique la dernière fois que les statistiques de votre schéma ont été mises à jour, ce qui est un bon indicateur d’« obsolescence ».
+ D’autres problèmes peuvent survenir, tels que le biais de distribution des données, lesquels ne seront pas pris en compte pour la cardinalité des tables. Pour plus d’informations, consultez [Estimation de la complexité d’ANALYZE TABLE pour les tables InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-analyze-table-complexity.html) et [Statistiques d’histogramme dans MySQL](https://dev.mysql.com/blog-archive/histogram-statistics-in-mysql/) dans la documentation MySQL.
## Comprendre le temps passé par les requêtes
Les éléments suivants permettent de déterminer le temps passé par les requêtes :
+ [Profilage](https://dev.mysql.com/doc/refman/8.0/en/show-profile.html)
+ [Schéma de performance](https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html)
+ [Optimiseur de requête](https://dev.mysql.com/doc/refman/8.0/en/controlling-optimizer.html)
**Profilage**
Par défaut, le profilage est désactivé. Activez le profilage, puis exécutez la requête lente et vérifiez son profil.
```
SET profiling = 1;
Run your query.
SHOW PROFILE;
```
1. Identifiez l’étape où la requête passe le plus de temps. Selon [États généraux des threads](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) dans la documentation MySQL, la lecture et le traitement des lignes d’une instruction `SELECT` est souvent l’état le plus long au cours de la durée de vie d’une requête donnée. Vous pouvez utiliser cette instruction `EXPLAIN` pour comprendre comment MySQL exécute cette requête.
1. Consultez le journal des requêtes lentes pour évaluer `rows_examined` et `rows_sent` afin de vous assurer que la charge de travail est similaire dans chaque environnement. Pour plus d’informations, consultez [Journalisation pour les bases de données Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
1. Exécutez la commande suivante pour les tables faisant partie de la requête identifiée :
```
SHOW TABLE STATUS\G;
```
1. Capturez les sorties suivantes avant et après l’exécution de la requête sur chaque environnement :
```
SHOW GLOBAL STATUS;
```
1. Exécutez les commandes suivantes sur chaque environnement pour voir si d'autres éléments query/session influencent les performances de cet exemple de requête.
```
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\G;
```
Parfois, lorsque les ressources du serveur sont occupées, cela a un impact sur toutes les autres opérations du serveur, y compris les requêtes. Vous pouvez également capturer des informations périodiquement lorsque des requêtes sont exécutées, ou configurer une tâche `cron` pour capturer des informations à des intervalles utiles.
**Schéma de performance**
Le schéma de performance fournit des informations utiles sur les performances d’exécution du serveur, tout en ayant un impact minimal sur ces performances. Il diffère de l’`information_schema`, qui fournit des informations de schéma sur l’instance de base de données. Pour plus d’informations, consultez [Présentation du schéma de performance pour Performance Insights sur Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
**Traçabilité de l’optimiseur de requête**
Pour comprendre pourquoi un [plan de requête particulier a été choisi pour être exécuté](https://dev.mysql.com/doc/refman/8.0/en/execution-plan-information.html), vous pouvez configurer `optimizer_trace` pour accéder à l’optimiseur de requêtes MySQL.
Exécutez une opération optimizer\$1trace pour afficher des informations détaillées sur tous les chemins disponibles pour l’optimiseur et sur son choix.
```
SET SESSION OPTIMIZER_TRACE="enabled=on";
SET optimizer_trace_offset=-5, optimizer_trace_limit=5;
-- Run your query.
SELECT * FROM table WHERE x = 1 AND y = 'A';
-- After the query completes:
SELECT * FROM information_schema.OPTIMIZER_TRACE;
SET SESSION OPTIMIZER_TRACE="enabled=off";
```
## Examen des paramètres de l’optimiseur de requêtes
Aurora MySQL version 3 (compatible avec MySQL 8.0 Community Edition) inclut de nombreuses modifications liées à l’optimiseur par rapport à Aurora MySQL version 2 (compatible avec MySQL 5.7 Community Edition). Si vous avez des valeurs personnalisées pour `optimizer_switch`, nous vous recommandons de vérifier les différences entre les valeurs par défaut et de définir les valeurs `optimizer_switch` les mieux adaptées à votre charge de travail. Nous vous recommandons également de tester les options disponibles pour Aurora MySQL version 3 afin d’examiner les performances de vos requêtes.
**Note**
Aurora MySQL version 3 utilise la valeur par défaut 20 pour le paramètre [innodb\$1stats\$1persistent\$1sample\$1pages](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_stats_persistent_sample_pages).
Vous pouvez utiliser la commande suivante pour afficher les valeurs `optimizer_switch` :
```
SELECT @@optimizer_switch\G;
```
Le tableau suivant affiche les valeurs `optimizer_switch` par défaut pour Aurora MySQL versions 2 et 3.
| Paramètre | Aurora MySQL version 2 | Aurora MySQL version 3 |
| --- | --- | --- |
| batched\$1key\$1access | off | off |
| block\$1nested\$1loop | on | on |
| condition\$1fanout\$1filter | on | on |
| derived\$1condition\$1pushdown | – | on |
| derived\$1merge | on | on |
| duplicateweedout | on | on |
| engine\$1condition\$1pushdown | on | on |
| firstmatch | on | on |
| hash\$1join | off | on |
| hash\$1join\$1cost\$1based | on | – |
| hypergraph\$1optimizer | – | off |
| index\$1condition\$1pushdown | on | on |
| index\$1merge | on | on |
| index\$1merge\$1intersection | on | on |
| index\$1merge\$1sort\$1union | on | on |
| index\$1merge\$1union | on | on |
| loosescan | on | on |
| materialization | on | on |
| mrr | on | on |
| mrr\$1cost\$1based | on | on |
| prefer\$1ordering\$1index | on | on |
| semijoin | on | on |
| skip\$1scan | – | on |
| subquery\$1materialization\$1cost\$1based | on | on |
| subquery\$1to\$1derived | – | off |
| use\$1index\$1extensions | on | on |
| use\$1invisible\$1indexes | – | off |
Pour plus d’informations, consultez [Optimisations remplaçables (MySQL 5.7](https://dev.mysql.com/doc/refman/5.7/en/switchable-optimizations.html)) et [Optimisations remplaçables (MySQL 8.0)](https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html) dans la documentation MySQL.