Aller au contenu

AWS Mis à jour le 2026-07-04

CPU RDS élevé : trouver la requête au lieu de grossir l'instance

Un CPU RDS cloué à 90-100 % vient presque toujours d'une poignée de requêtes, pas d'un matériel trop petit. Voici comment les trouver avec Performance Insights et corriger la cause avant de payer pour une instance plus grosse.

Une instance RDS clouée à 90-100 % de CPU, ce n’est presque jamais « l’instance est trop petite » — c’est habituellement deux ou trois requêtes qui font beaucoup plus de travail qu’elles ne le devraient, multipliées par le volume de requêtes applicatives. Ouvrez Performance Insights, triez par CPU, et les coupables sont sur le premier écran. Grossir l’instance sans faire cette étape fonctionne, coûte de l’argent réel chaque mois, et dure exactement jusqu’à ce que le trafic remplisse la nouvelle marge.

Ce qui se passe

Le CPU d’une base de données va à un petit nombre de choses : évaluer des lignes (parcours complets de tables, grosses jointures, tris), analyser et planifier les requêtes, et — sur les classes burstables — parfois rien du tout, parce que la vraie histoire, ce sont les crédits CPU. Chacune est visible si on regarde au bon endroit.

Le patron qu’on voit le plus souvent : une requête correcte à 100 k lignes devient un parcours-et-tri à 10 M de lignes. Elle répond encore en 300 ms, donc personne ne s’en aperçoit, mais elle brûle un cœur complet par exécution, et à 50 exécutions par seconde, l’instance sature. Deuxième cas le plus fréquent : un ORM qui émet des tempêtes de requêtes N+1 — des milliers de requêtes bon marché dont le coût d’analyse et de réseau par instruction s’additionne en un CPU cloué, sans aucune « requête lente » à trouver. Troisième : un index manquant après un changement de schéma ou une nouvelle fonctionnalité, qui transforme des recherches ponctuelles en parcours.

Le piège des classes burstables mérite son propre paragraphe. Sur les instances db.t3 et db.t4g, un CPU soutenu au-dessus de la base dépense des crédits. Quand CPUCreditBalance atteint zéro (en mode standard), l’instance est bridée à sa base — la charge n’a pas changé, mais tout est devenu plus lent, et le CPU paraît élevé parce que le plafond a baissé. Si vous exécutez la production sur une classe t, vérifiez les métriques de crédits avant tout le reste.

Quoi vérifier en premier

  • La forme de CPUUtilization dans RDS > Databases > votre-instance > Monitoring — un changement en escalier pointe vers un déploiement ou un seuil de taille de données franchi; une rampe quotidienne pointe vers le trafic; un plateau à 100 % après une montée lente sur une classe t pointe vers les crédits.
  • CPUCreditBalance si la classe commence par db.t — un solde à zéro, c’est votre réponse.
  • Si Performance Insights est activé. Il l’est par défaut sur la plupart des chemins de création modernes et le palier gratuit conserve 7 jours; s’il est désactivé, activez-le maintenant — vous en aurez aussi besoin pour chaque incident futur.
  • Ce qui a changé — déploiements, migrations, un envoi marketing, l’horaire d’une tâche par lots.
  • Enhanced Monitoring pour confirmer que le CPU va au processus du moteur et non, par exemple, à une rafale de swap au niveau de l’OS.

Comment vérifier

Performance Insights est l’outil principal. Console : RDS > Performance insights, choisissez l’instance, réglez la plage de temps sur l’incident, et découpez la charge par Top SQL. Le graphique de charge (sessions actives moyennes) découpé par état d’attente vous dit si la charge est du CPU ou de l’attente sur l’I/O et les verrous — ce sont d’autres articles.

Depuis la CLI, les mêmes données :

aws pi get-resource-metrics \
  --service-type RDS \
  --identifier db-ABCDEFGHIJKL123 \
  --metric-queries '[{"Metric":"db.load.avg","GroupBy":{"Group":"db.sql_tokenized","Limit":5}}]' \
  --start-time 2026-07-04T08:00:00Z --end-time 2026-07-04T10:00:00Z \
  --period-in-seconds 300

Dans le moteur, confirmez ce que font les instructions en tête :

-- Postgres : instructions en tête par temps total (requiert pg_stat_statements)
SELECT calls, ROUND(total_exec_time::numeric/1000,1) AS total_s,
       ROUND(mean_exec_time::numeric,2) AS mean_ms, LEFT(query,80)
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

-- MySQL : instructions en tête depuis performance_schema
SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1e12 AS total_s
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

Ensuite, lancez EXPLAIN (Postgres : EXPLAIN (ANALYZE, BUFFERS)) sur l’instruction en tête et cherchez les parcours séquentiels et les tris sur de gros volumes de lignes.

Le correctif

  1. Identifier les deux ou trois instructions en tête par charge. Dans chaque incident réel qu’on a traité, les trois premières instructions représentaient 60-90 % de la charge. Ne réglez pas la longue traîne.
  2. Corriger le chemin d’accès. Ajoutez l’index manquant, réécrivez la requête pour utiliser un index existant, ou poussez le filtrage dans la base de données au lieu de récupérer puis jeter. Un seul index a, plus d’une fois dans notre expérience, fait passer une instance de 95 % de CPU à 20 %.
  3. Tuer le N+1. Si l’instruction en tête est triviale mais s’exécute des dizaines de milliers de fois par minute, le correctif est dans l’application : chargement anticipé de l’association ou regroupement des recherches. Aucun index n’aide ici.
  4. Mettre en cache ce que la base recalcule sans arrêt. Un classement, un bloc de paramètres, un agrégat de tableau de bord frappé à chaque requête a sa place dans ElastiCache ou en mémoire applicative avec un TTL court.
  5. Déplacer les lectures vers un réplica si la charge est réellement du volume de lecture déjà efficace — voyez réplicas de lecture dans un SaaS multi-locataires pour les mises en garde sur le lag avant d’y router du trafic.
  6. Ensuite, et seulement ensuite, redimensionner. Si les requêtes en tête sont déjà efficaces, que la charge est réelle et toujours élevée, montez la classe d’instance — ou passez une classe t en mode unlimited ou vers une classe m/r si les crédits étaient l’histoire. C’est la bonne dernière étape, pas le premier réflexe.

Quand c’est la mauvaise approche

Si Performance Insights montre une charge dominée par les attentes d’I/O (IO:DataFileRead, io/table/sql/handler) plutôt que du CPU, le goulot est le stockage, pas le calcul — une instance plus grosse n’achète surtout que plus de cache de pages, et le correctif honnête, ce sont les index ou les IOPS. Si le CPU est élevé mais stable à 40-60 % et que la latence est bonne, vous n’avez peut-être aucun problème; une base de données a le droit de travailler. Et pendant une vraie poussée de trafic avec des requêtes efficaces, redimensionner est le bon geste — cet article s’oppose au redimensionnement irréfléchi, pas à la capacité. La documentation Amazon RDS couvre les paliers de rétention de Performance Insights si la fenêtre gratuite ne suffit pas.

Erreurs fréquentes

  • Redimensionner d’abord, conclure « ça a réglé le problème », et ne jamais trouver la requête qui clouera la plus grosse instance dans six mois.
  • Ignorer CPUCreditBalance sur les instances de classe t et déboguer un bridage comme si c’était de la charge.
  • Régler selon mean_exec_time seulement — une requête de 2 ms appelée 100 k fois/minute pèse plus lourd qu’un rapport de 4 secondes qui tourne chaque heure.
  • Redémarrer l’instance pour « vider » le CPU : vous perdez le pool de tampons/cache, et le réchauffement rend l’heure suivante pire.

Prévention

  • Alarme sur le p95 du CPU au-dessus de 80 % soutenu 15 minutes, pas sur les pics instantanés.
  • Gardez Performance Insights activé partout; sept jours de rétention gratuite ont résolu la plupart de nos incidents.
  • Révisez le top SQL chaque mois — les requêtes se dégradent quand les données grandissent, et la révision les attrape à 40 % de CPU au lieu de 100 %.
  • Lancez EXPLAIN sur les nouvelles requêtes qui touchent de grosses tables dans le cadre de la revue de code.
  • Sortez la production des classes burstables dès que le CPU de base dépasse à peu près la base de la classe; le calcul des crédits cesse de jouer en votre faveur.

Un CPU élevé, c’est la base de données qui vous dit exactement quelle requête corriger, via Performance Insights, gratuitement — redimensionner, c’est payer chaque mois pour ne pas écouter. 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.