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.
# Présentation de Performance Insights sur Amazon Aurora
**Important**
AWS a annoncé la end-of-life date de Performance Insights : le 30 juin 2026. Après cette date, Amazon RDS ne prendra plus en charge l’expérience de la console Performance Insights, les périodes de conservation flexibles (1 à 24 mois) et les tarifs associés. L’API Performance Insights continuera d’exister sans modification de prix. Les coûts de l'API Performance Insights apparaîtront sur votre AWS facture avec le coût de CloudWatch Database Insights.
Nous vous recommandons de mettre à niveau toutes les de base de données de clusters de bases de données utilisant le niveau payant de Performance Insights vers le mode avancé de Database Insights avant le 30 juin 2026. Pour en savoir plus sur la mise à niveau vers le mode avancé de Database Insights, consultez [Activation du mode Avancé de Database Insights pour Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).
Si vous n’effectuez aucune action, les clusters de bases de données utilisant Performance Insights utiliseront par défaut le mode Standard de Database Insights. Avec le mode Standard de Database Insights, vous risquez de perdre l’accès à l’historique des données de performance au-delà de 7 jours et de ne pas être en mesure d’utiliser les plans d’exécution et les fonctionnalités d’analyse à la demande dans la console Amazon RDS. Après le 30 juin 2026, seul le mode avancé de Database Insights prendra en charge les plans d'exécution et les analyses à la demande.
Avec CloudWatch Database Insights, vous pouvez surveiller la charge de base de données de votre parc de bases de données et analyser et résoudre les problèmes de performance à grande échelle. Pour plus d’informations sur Database Insights, consultez [Surveillance des bases de données Amazon Aurora à l’aide de CloudWatch Database Insights](USER_DatabaseInsights.md). Pour plus d'informations sur les tarifs, consultez [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
Par défaut, RDS active Performance Insights dans l’assistant de création de console pour les moteurs Amazon RDS. Si vous activez Performance Insights au niveau du cluster de bases de données, RDS active Performance Insights pour chaque instance de base de données du cluster. Si vous disposez de plusieurs bases de données sur une instance de base de données, Performance Insights regroupe les données de performance.
Vous trouverez un aperçu de Performance Insights pour Amazon Aurora dans la vidéo suivante.
[](http://www.youtube.com/watch?v=yOeWcPBT458)
**Topics**
+ [Charge de base de données](USER_PerfInsights.Overview.ActiveSessions.md)
+ [Utilisation maximale de l’UC](USER_PerfInsights.Overview.MaxCPU.md)
+ [Support du moteur de base de données , des régions et des classes d'instance Amazon Aurora pour Performance Insights](USER_PerfInsights.Overview.Engines.md)
+ [Tarification et conservation des données pour Performance Insights](USER_PerfInsights.Overview.cost.md)
# Charge de base de données
*Charge de base de données* mesure le niveau d’activité de la session de votre base de données. `DBLoad` est la métrique clé de Performance Insights, et Performance Insights collecte la charge de base de données chaque seconde.
**Topics**
+ [Sessions actives](#USER_PerfInsights.Overview.ActiveSessions.active-sessions)
+ [Sessions actives en moyenne](#USER_PerfInsights.Overview.ActiveSessions.AAS)
+ [Exécutions actives moyennes](#USER_PerfInsights.Overview.ActiveSessions.AAE)
+ [Dimensions](#USER_PerfInsights.Overview.ActiveSessions.dimensions)
## Sessions actives
Une *session de base de données* représente le dialogue d’une application avec une base de données relationnelle. Une session active est une connexion qui a transmis du travail au moteur de base de données et qui attend une réponse.
Une session est active lorsqu’elle s’exécute sur le processeur (CPU) ou attend qu’une ressource devienne disponible pour pouvoir continuer. Par exemple, une session active peut attendre qu’une page (ou un bloc) soit lue en mémoire avant d’utiliser le processeur pendant la lecture des données de la page.
## Sessions actives en moyenne
Les *sessions actives en moyenne (AAS)* représentent l’unité de la métrique `DBLoad` de Performance Insights. Elle mesure le nombre de sessions actives simultanément sur la base de données.
Toutes les secondes, Performance Insights échantillonne le nombre de sessions exécutant simultanément une requête. Pour chaque session active, Performance Insights collecte les données suivantes :
+ Instruction SQL
+ État de la session (en cours d’exécution sur le processeur ou en attente)
+ Host (Hôte)
+ Utilisateur exécutant le SQL
Performance Insights calcule les AAS en divisant le nombre total de sessions par le nombre d’échantillons pour une période déterminée. Par exemple, la table suivante présente 5 échantillons consécutifs d’une requête en cours d’exécution, prélevés à des intervalles d’une seconde.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html)
Dans l’exemple précédent, la charge de la base de données pour l’intervalle de temps était de 2 AAS. Cette mesure signifie qu’en moyenne, deux sessions étaient actives à la fois à n’importe quel moment au cours de la période où les cinq échantillons ont été prélevés.
## Exécutions actives moyennes
La moyenne des exécutions actives (AAE) par seconde est liée à l’AAS. Pour calculer l’AAE, Performance Insights divise la durée totale d’exécution d’une requête par l’intervalle de temps. Le tableau suivant présente le calcul de l’AAE pour la même requête que dans le tableau précédent.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html)
Dans la plupart des cas, l’AAS et l’AAE d’une requête sont approximativement identiques. Cela dit, comme les données utilisées pour les calculs proviennent de sources différentes, les calculs varient souvent légèrement.
## Dimensions
La métrique `db.load` est différente des autres métriques de séries chronologiques, car vous pouvez la décomposer en sous-composants appelés dimensions. Vous pouvez considérer les dimensions comme des catégories de « tranches » pour les différentes caractéristiques de la métrique `DBLoad`.
Lorsque vous diagnostiquez des problèmes de performances, les dimensions suivantes sont souvent les plus utiles :
**Topics**
+ [Événements d’attente](#USER_PerfInsights.Overview.ActiveSessions.waits)
+ [Principaux éléments SQL](#USER_PerfInsights.Overview.ActiveSessions.top-sql)
Pour obtenir la liste complète des dimensions des moteurs Aurora, consultez [Charge de base de données tranchée par dimensions](USER_PerfInsights.UsingDashboard.Components.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.dims).
### Événements d’attente
Un *événement d’attente* fait qu’une instruction SQL attend qu’un événement spécifique se produise avant de pouvoir continuer à s’exécuter. Les événements d’attente constituent une dimension (ou catégorie) importante pour la charge de la base de données, car ils indiquent les points de blocage du travail.
Chaque session active est soit en cours d’exécution au niveau du processeur soit en attente. Par exemple, les sessions sollicitent le processeur lorsqu’elles recherchent un tampon dans la mémoire, effectuent un calcul ou exécutent du code procédural. Lorsque les sessions ne sollicitent pas le processeur, c’est peut-être qu’elles attendent qu’un tampon de mémoire se libère, qu’un fichier de données soit lu ou qu’un journal soit écrit. Le temps que passe une session à attendre des ressources est autant de temps en moins qu’elle passe à s’exécuter au niveau du processeur.
Lorsque vous réglez une base de données, vous cherchez souvent à identifier les ressources que les sessions attendent. Par exemple, deux ou trois événements d’attente peuvent représenter 90 % de la charge de la base de données. Cette mesure signifie qu’en moyenne, les sessions actives passent la majeure partie de leur temps à attendre un petit nombre de ressources. Si vous trouvez la cause de ces attentes, vous pouvez tenter une solution.
Les événements d’attente varient en fonction du moteur de base de données :
+ Pour obtenir la liste des événements d’attente courants pour Aurora MySQL, consultez [Événements d’attente Aurora MySQL](AuroraMySQL.Reference.Waitevents.md). Pour savoir comment régler l’utilisation de ces événements d’attente, consultez [Réglage d'Aurora MySQL](AuroraMySQL.Managing.Tuning.md).
+ Pour plus d’informations sur tous les événements d’attente MySQL, consultez [Wait Event Summary Tables](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-wait-summary-tables.html) dans la documentation MySQL.
+ Pour obtenir la liste des événements d’attente courants pour Aurora PostgreSQL, consultez [Événements d’attente Amazon Aurora PostgreSQL](AuroraPostgreSQL.Reference.Waitevents.md). Pour savoir comment régler l’utilisation de ces événements d’attente, consultez [Réglage des événements d’attente pour Aurora PostgreSQL](AuroraPostgreSQL.Tuning.md).
+ Pour plus d’informations sur tous les événements d’attente PostgreSQL, consultez [The Statistics Collector > Wait Event tables](https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-TABLE) dans la documentation de PostgreSQL.
### Principaux éléments SQL
Là où les événements d’attente présentent des goulots d’étranglement, les principaux éléments SQL indiquent quelles requêtes contribuent le plus à la charge de la base de données. Par exemple, de nombreuses requêtes peuvent être en cours d’exécution sur la base de données, mais une seule d’entre elles peut consommer 99 % de la charge de la base de données. Dans ce cas, la charge élevée peut indiquer un problème avec la requête.
Par défaut, la console Performance Insights affiche les principales requêtes SQL qui contribuent à la charge de la base de données. La console affiche également des statistiques pertinentes pour chaque instruction. Pour diagnostiquer les problèmes de performances d’une instruction spécifique, vous pouvez examiner son plan d’exécution.
# Utilisation maximale de l’UC
Dans le tableau de bord, le graphique **Database load** (Charge de base de données)collecte, regroupe et affiche les informations de session. Pour voir si les sessions actives dépassent l’utilisation maximale de l’UC, examinez leur relation sur la ligne **Max vCPU** (UC virtuelle max). Performance Insights détermine la valeur de **vCPU maximum** par le nombre de cœurs de vCPU (UC virtuelle) pour votre instance de base de données. Pour Aurora sans serveur v2, le **vCPU maximum** représente le nombre estimé de vCPU.
Un seul processus peut être exécuté sur un vCPU à la fois. Si le nombre de processus dépasse le nombre de vCPU, les processus sont mis en file d’attente. Lorsque le nombre de processus en file d’attente augmente, les performances de la base de données diminuent. Si la charge de la base de données est souvent au-dessus de la ligne **Max vCPU** (UC virtuelle max)et que l’état d’attente principal est CPU, cela signifie que l’UC est surchargée. Dans ce cas, vous pouvez décider de limiter les connexions à l’instance, de régler les requêtes SQL avec une charge d’UC élevée, ou envisager l’utilisation d’une classe d’instance plus grande. Quel que soit leur état d’attente, les instances élevées et régulières indiquent que des problèmes de goulots d’étranglement ou de conflits de ressources devront peut-être être résolus. Cela peut être vrai même si la charge de la base de données ne dépasse pas la ligne **Max vCPU** (UC virtuelle max).
# Support du moteur de base de données , des régions et des classes d'instance Amazon Aurora pour Performance Insights
**Important**
AWS a annoncé la end-of-life date de Performance Insights : le 30 juin 2026. Après cette date, Amazon RDS ne prendra plus en charge l’expérience de la console Performance Insights, les périodes de conservation flexibles (1 à 24 mois) et les tarifs associés. L’API Performance Insights continuera d’exister sans modification de prix. Les coûts de l'API Performance Insights apparaîtront sur votre AWS facture avec le coût de CloudWatch Database Insights.
Nous vous recommandons de mettre à niveau toutes les de base de données de clusters de bases de données utilisant le niveau payant de Performance Insights vers le mode avancé de Database Insights avant le 30 juin 2026. Pour en savoir plus sur la mise à niveau vers le mode avancé de Database Insights, consultez [Activation du mode Avancé de Database Insights pour Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md).
Si vous n’effectuez aucune action, les clusters de bases de données utilisant Performance Insights utiliseront par défaut le mode Standard de Database Insights. Avec le mode Standard de Database Insights, vous risquez de perdre l’accès à l’historique des données de performance au-delà de 7 jours et de ne pas être en mesure d’utiliser les plans d’exécution et les fonctionnalités d’analyse à la demande dans la console Amazon RDS. Après le 30 juin 2026, seul le mode avancé de Database Insights prendra en charge les plans d'exécution et les analyses à la demande.
Avec CloudWatch Database Insights, vous pouvez surveiller la charge de base de données de votre parc de bases de données et analyser et résoudre les problèmes de performance à grande échelle. Pour plus d’informations sur Database Insights, consultez [Surveillance des bases de données Amazon Aurora à l’aide de CloudWatch Database Insights](USER_DatabaseInsights.md). Pour plus d'informations sur les tarifs, consultez [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
Le tableau suivant fournit les moteurs de base de données Amazon Aurora qui prennent en charge l’analyse des performances.
| Moteur de base de données Amazon Aurora | Versions et régions soumises à la gestion des versions du moteur | Restrictions de classe d’instance |
| --- | --- | --- |
| Amazon Aurora MySQL-Compatible Edition | Pour plus d’informations sur la disponibilité des versions et des régions de Performance Insights avec Aurora MySQL, consultez [Performance Insights avec Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.amy). | Performance Insights présente les restrictions de classe de moteur suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.Engines.html) |
| Amazon Aurora PostgreSQL-Compatible Edition | Pour plus d’informations sur la disponibilité des versions et des régions de Performance Insights avec Aurora PostgreSQL, consultez [Performance Insights avec Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.apg). | N/A |
## Support du moteur de base de données , des régions et des classes d'instance Amazon Aurora pour les fonctionnalités Performance Insights
Le tableau suivant fournit les moteurs de base de données Amazon Aurora qui prennent en charge les fonctionnalités d’analyse des performances.
| Fonctionnalité | [Niveau de tarification](https://aws.amazon.com/rds/performance-insights/pricing/) | [Régions prises en charge](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions) | Moteurs de base de données pris en charge | [Classes d’instance prises en charge](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html#Concepts.DBInstanceClass.Types) |
| --- | --- | --- | --- | --- |
| [Statistiques SQL pour Performance Insights](sql-statistics.md) | Tous | Tous | Tous | Tous |
| [Analyse des performances de base de données pour une période donnée](USER_PerfInsights.UsingDashboard.AnalyzePerformanceTimePeriod.md) | Niveau payant uniquement | Tous | Tous | Toutes sauf db.serverless (Aurora Serverless v2) |
| [Affichage des recommandations proactives de Performance Insights](USER_PerfInsights.InsightsRecommendationViewDetails.md) | Niveau payant uniquement | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.Engines.html) | Tous | Toutes sauf db.serverless (Aurora Serverless v2) |
# Tarification et conservation des données pour Performance Insights
Par défaut, Performance Insights qui comprend 7 jours d’historique des données de performance et 1 million de demandes API par mois. Vous pouvez également acheter des périodes de conservation plus longues. Pour des informations complètes sur les prix, consultez la section [Performance Insights Pricing](https://aws.amazon.com/rds/performance-insights/pricing/) (Tarification de Performance Insights).
Dans la console RDS, vous pouvez choisir l’une des périodes de conservation suivantes pour vos données Performance Insights :
+ **Par défaut (7 jours)**
+ ***n* mois**, où ***n*** est un nombre allant de 1 à 24
![\[Choisissez une période de conservation pour vos données Performance Insights.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-retention-periods.png)
Pour savoir comment définir une période de conservation à l’aide de AWS CLI, consultez [Activation ou désactivation de l’Analyse des performances pour Aurora](USER_PerfInsights.Enabling.md).
**Note**
L’arrêt d’un cluster de bases de données alors que Performance Insights est activé n’a aucune incidence sur la conservation des données. En cas d’arrêt d’un cluster de bases de données, Performance Insights ne collecte aucune donnée.