Aller au contenu

AWS Mis à jour le 2026-09-15

Performance Insights sur RDS : lire la charge par événement d'attente pour trouver le vrai goulot

Apprenez à lire le tableau de bord Performance Insights d'Amazon RDS pour comprendre pourquoi votre base de données est lente. Ce guide vous montre comment comparer la charge de la base au nombre de processeurs et ce que chaque événement d'attente dominant vous dit de corriger.

Ce guide montre aux développeurs et aux opérateurs comment utiliser Performance Insights d’Amazon RDS pour trouver pourquoi une base de données est lente. Performance Insights est le tableau de bord d’AWS qui enregistre combien de sessions sont occupées à chaque instant et ce qu’elles attendent. La plainte habituelle reste floue. L’application semble lente, le CPU a l’air correct, et personne ne sait s’il faut ajouter un index, prendre une plus grosse instance ou regarder du côté de l’application.

La réponse tient dans un seul graphique, lu de la bonne façon. Il trace la charge en sessions actives moyennes (AAS, pour average active sessions), soit le nombre de sessions qui travaillent ou attendent en même temps. Cette charge se lit face au nombre de vCPU (les processeurs virtuels) de l’instance. Quand la charge dépasse cette ligne, la base est saturée. Un événement d’attente est l’étiquette qui dit ce que chaque session attend. Le découpage par événement d’attente montre si la pression vient du CPU, des lectures disque, des verrous ou des vidages de commit (l’écriture sur disque qu’attend chaque transaction confirmée).

Ce qui se passe

Chaque seconde, le moteur échantillonne les sessions actives et leur état. Une session active est soit en exécution sur le CPU, soit en attente de quelque chose — une lecture I/O, un verrou tenu par une autre transaction, un vidage WAL/redo, le client lui-même. Performance Insights agrège ces échantillons en charge DB (AAS) et vous laisse la découper par événement d’attente, requête SQL, hôte, utilisateur ou base.

Le modèle mental, c’est la capacité contre la demande. Une instance à 8 vCPU peut exécuter simultanément le travail CPU de 8 sessions; un AAS à 2 signifie une marge confortable, un AAS à 15 signifie que sept sessions sont en file ou en attente à chaque instant. Mais la composition compte plus que le chiffre :

  • CPU dominant — les requêtes font le travail; le correctif est dans les plans de requêtes, les index ou plus de calcul.
  • Attentes I/O dominantes (IO:DataFileRead sur PostgreSQL, io/file/innodb/innodb_data_file sur MySQL) — le jeu de travail ne tient pas en mémoire ou les requêtes balaient trop; le correctif est dans les index, la forme des requêtes ou plus de RAM, pas plus de CPU.
  • Attentes de verrous dominantes (Lock:transactionid, Lock:tuple sur PostgreSQL; familles de mutex synch/ sur MySQL) — les sessions se bloquent entre elles; le correctif est dans les patrons de transactions de l’application, et aucune taille d’instance n’aidera.
  • Attentes de commit dominantes (LWLock:WALWrite, IO:XactSync sur Aurora PostgreSQL; événements de synchronisation binlog sur MySQL) — charge d’écriture qui vide à chaque commit; le correctif est le regroupement, ou accepter le coût de durabilité.
  • Client:ClientRead / attentes réseau — la base attend que le client consomme les résultats; le goulot est la couche applicative ou un chemin réseau lent, et régler la base est de l’effort gaspillé.

La rétention du palier gratuit est de 7 jours; une rétention plus longue est payante, et AWS intègre progressivement cet outillage dans CloudWatch Database Insights, où la même analyse charge-par-attente se transpose. Les détails de support par fonctionnalité et moteur sont dans la documentation RDS sur https://docs.aws.amazon.com/rds/.

Quoi vérifier en premier

  • Si Performance Insights est même activé — c’est un réglage par instance, et il ne peut pas vous montrer un incident pour lequel il était éteint.
  • La ligne vCPU sur le graphique de charge — tout se lit par rapport à elle, donc connaissez la classe d’instance.
  • La fenêtre de temps — zoomez sur la fenêtre de l’incident; une moyenne sur la journée aplatit le pic qui vous intéresse.
  • Si le patron est nouveau — comparez les mêmes heures la semaine passée avant de déclarer une urgence.
  • Réplica vs writer — vérifiez quelle instance vous regardez; les réplicas en lecture ont leurs propres tableaux de bord et leurs propres problèmes, surtout dans les conceptions à réplicas de lecture.

Comment vérifier

Console : RDS > Performance Insights, choisissez l’instance, réglez Slice by sur Waits. Les couleurs empilées sous la ligne de charge sont votre diagnostic; l’onglet Top SQL en dessous attribue la même charge aux requêtes.

Les mêmes données sont scriptables — notez que l’API utilise le DbiResourceId, pas le nom de l’instance :

aws pi describe-dimension-keys \
  --service-type RDS \
  --identifier db-ABCDEFGHIJKL123 \
  --metric db.load.avg \
  --group-by '{"Group":"db.wait_event"}' \
  --start-time 2026-07-03T13:00:00Z \
  --end-time 2026-07-03T15:00:00Z \
  --period-in-seconds 300

Remplacez --group-by par {"Group":"db.sql_tokenized"} pour classer les requêtes par la charge qu’elles génèrent. Recoupez avec les bases CloudWatch (CPUUtilization, ReadIOPS, FreeableMemory) — Performance Insights vous dit sur quoi les sessions attendent; CloudWatch vous dit ce que fait l’hôte.

La marche à suivre

  1. Établissez s’il y a saturation ou non. Un AAS sous la ligne vCPU avec une application lente signifie habituellement que le problème n’est pas la capacité de la base — regardez Client:ClientRead, l’acquisition de connexions dans l’application, ou le réseau avant de toucher à l’instance.
  2. Identifiez l’attente dominante durant la mauvaise fenêtre. Un événement d’attente possède habituellement la moitié ou plus de la charge. Cet événement choisit le plan de match — ne sautez pas vers un correctif favori.
  3. Attribuez-la au SQL. Découpez par Top SQL sur la même fenêtre. Neuf fois sur dix, une ou deux requêtes tokenisées portent la charge; capturez-les et lancez EXPLAIN/EXPLAIN ANALYZE avec des paramètres réalistes.
  4. Appliquez le correctif propre à l’attente. Lectures I/O : ajoutez l’index manquant ou élargissez la mémoire. CPU : corrigez le plan ou augmentez le calcul. Verrous : raccourcissez les transactions et corrigez les tempêtes de reprise dans l’application. Vidages de commit : regroupez les écritures, revoyez synchronous_commit/les réglages binlog contre vos exigences de durabilité — les changements de paramètres appartiennent à un diff de parameter group révisé, pas à une retouche à chaud dans la console.
  5. Vérifiez sur le même graphique. Après le changement, la même forme de fenêtre devrait montrer l’attente dominante rétrécie et l’AAS total plus bas — pas juste « l’application semble plus vite ».
  6. Consignez la référence. Capture d’écran ou export du profil de charge sain; le prochain incident se diagnostique par diff, ce qui est beaucoup plus rapide.

Quand c’est la mauvaise approche

Performance Insights échantillonne les sessions — il n’attrapera pas une requête de 30 millisecondes exécutée un million de fois à moins qu’elle apparaisse dans la charge agrégée. Il ne dit rien non plus des problèmes hors de la base : épuisement du pool de connexions dans l’application, DNS, ou un chemin NAT saturé. L’analyse de micro-latence sous la seconde appartient aux outils du moteur (percentiles de pg_stat_statements, journal des requêtes lentes). Et si l’instance est simplement sous-dimensionnée pour une charge qui a doublé, aucune lecture d’événements d’attente ne remplace la conversation sur la capacité.

Erreurs courantes

  • Lire l’AAS comme un pourcentage de CPU — 60 % de CPU avec un AAS à trois fois les vCPU est une crise; 95 % de CPU avec un AAS sous les vCPU peut être une machine saine et bien utilisée.
  • Régler la base pour des attentes Client:ClientRead qui appartiennent à la couche applicative.
  • Moyenner sur une journée et conclure « la charge est correcte » quand le pic de 14 h est tout le problème.
  • Laisser Performance Insights éteint pour économiser la rétention payante, puis avoir 7 jours d’historique qui n’incluent pas l’incident dont tout le monde parle.

Garder le contrôle

  • Activez Performance Insights sur chaque instance de production; le palier de rétention par défaut ne coûte rien.
  • Alarme sur DBLoad relatif au nombre de vCPU dans CloudWatch, pas seulement sur le CPU.
  • Revoyez la liste Top SQL chaque mois — la composition de la charge dérive bien avant que les clients se plaignent.
  • Jumelez-le avec pg_stat_statements ou le performance schema de MySQL pour que le chronométrage par requête appuie le portrait par session.

Le graphique charge-par-attente est la réponse honnête la plus rapide qu’AWS offre à « pourquoi la base est lente » — apprenez à le lire avant l’incident, pas pendant. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.