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.
Exécution lente de la requête
Identification - Détectez le problème
Une requête lente est une requête qui dépasse le délai d'exécution prévu pour les besoins de votre entreprise. La définition de ce qui constitue une requête lente varie selon les charges de travail. Vous pouvez identifier les requêtes lentes grâce aux journaux du profileur ou à Performance Insights.
-
Activez le profileur s'il n'est pas déjà activé. Les journaux du profileur sont écrits sur Amazon CloudWatch sous le groupe de journaux :
/aws/docdb/<cluster-identifier>/profiler. Utilisez CloudWatch Logs Insights pour les interroger.Exemple de requête d'analyse de CloudWatch journal pour obtenir les 10 requêtes les plus lentes pour la collection ecommerce.products :
filter ns="ecommerce.products" | sort millis desc | limit 10 -
Utilisez Performance Insights pour identifier les requêtes coûteuses en temps quasi réel. Activez Performance Insights s'il n'est pas déjà activé.
-
Ouvrez la AWS console, accédez à Amazon DocumentDB, puis à Performance Insights, puis sélectionnez votre instance de cluster.
-
Consultez la chronologie du chargement de la base de données (AAS) et les principales requêtes (par charge de base de données). Développez un résumé de requête pour afficher les instructions secondaires littérales.
-
Capturez les requêtes qui nécessitent une analyse.
Note
Les requêtes de Performance Insights ne sont peut-être pas toutes inefficaces ou lentes.
-
Enquêter — Recueillir des informations
-
Le profileur fournit le plan d'exécution des requêtes et les indicateurs clés qui y sont associés, notamment millis, nreturned et PlanSummary (utilisation de l'index) :
{ "op": "query", "ts": 1721374275673, "ns": "test.perf", "command": { "find": "perf", "filter": { "threadRunCount": 0 }, "$db": "test", "lsid": { "id": { "$binary": "oO2wEtpgQIK+y9KGByYnsw==", "$type": "4" } }, "$readPreference": { "mode": "secondaryPreferred" } }, "cursorExhausted": true, "nreturned": 0, "responseLength": 0, "protocol": "op_query", "millis": 137, "planSummary": "IXSCAN", "execStats": { "stage": "FETCH", "nReturned": "0", "executionTimeMillisEstimate": "100.346", "inputStage": { "stage": "IXSCAN", "nReturned": "0", "executionTimeMillisEstimate": "100.342", "indexName": "threadRunCount_1" } }, "client": "172.31.6.165:43154", "appName": "ProdAppTester14", "user": "adminuser" }Pour rechercher les requêtes COLLSCAN, procédez comme suit :
filter planSummary="COLLSCAN" | sort millis desc | limit 20 -
Utilisez Performance Insights pour analyser les tendances d'exécution des requêtes, telles que les temps d'attente, la charge et l'impact sur les ressources (par exemple, les IOPS ou le processeur par requête) en temps réel.
Performance Insights ne fournissant pas le plan d'exécution de la requête, capturez la requête et exécutez explain (« ExecutionStats ») sur la requête sur votre cluster Amazon DocumentDB :
db.ecommerce.products.find().explain("executionStats") -
Corrélez éventuellement les métriques du profileur avec les données de Performance Insights (par exemple, faites correspondre les requêtes à haut millième dans le profileur aux requêtes les plus fréquentes dans Performance Insights).
Diagnostiquer — Trouver la cause première
Au cours de cette étape, diagnostiquez le plan de requête afin d'identifier les optimisations potentielles. Utilisez le flux suivant : symptôme → cause probable :
-
Symptôme : Résumé du plan : « COLLSCAN »
Cause : index manquant ou incorrect.
-
Symptôme : agrégation lente avec $group/$sort
Cause : le pipeline d'agrégation traite peut-être trop de données en mémoire.
-
Symptôme : latences élevées alors que Performance Insights affiche la charge de base de données groupée par temps d'attente, bien que des index soient utilisés (PlanSummary : « IXSCAN »).
Cause : requêtes I/O liées ; les index ou l'ensemble de travail dépassent le cache tampon disponible sur l'instance.
-
Symptôme : le PI indique les états d'attente du processeur, un AAS élevé en raison du faible nombre de requêtes
Cause : CPU-bound requêtes (agrégations complexes, $regex).
-
Symptôme : de nombreuses requêtes lentes, mais aucune n'affiche un PlanSummary coûteux
Cause : goulot d'étranglement externe (réseau, régulation, tâches de maintenance, volume de requêtes).
Résoudre — Résoudre le problème
Lorsque vous implémentez des correctifs, validez toujours avec explain (« ExecutionStats ») et surveillez le chargement de la base de données Performance Insights.
-
Résumé du plan : « COLLSCAN »
-
Créez un index ciblé.
Exemple : pour les requêtes fréquentes qui filtrent par {catégorie, prix} et trient par prix décroissant :
db.products.createIndex({ category: 1, price: -1 })
-
-
agrégation lente avec $group/$sort
-
Appuyez tôt sur $match et $project pour réduire le flux de documents dans $group/$sort.
-
Limitez le nombre de champs au début du pipeline :
db.products.explain("executionStats").aggregate([ { $match: { category: "Electronics", price: { $gt: 0 } } }, // early filter { $project: { price: 1, category: 1 } }, // reduce document size { $group: { _id: "$category", avgPrice: { $avg: "$price" } } } ])
-
-
latences élevées tandis que Performance Insights indique la charge de base de données groupée par temps d'attente
-
Vérifiez si la valeur BufferCacheHitRatio est faible ou si le nombre de ReadiOps sur l'instance est élevé. Augmentez la mémoire de l'instance (mettez à niveau la classe d'instance, par exemple, r6g.large → r6g.xlarge) ou utilisez la classe d'instance NVMe.
-
Réduisez l'empreinte de l'indice.
-
Ajoutez des répliques de lecture pour décharger le trafic de lecture (utilisez le paramètre ReadPreference pour rediriger le trafic sur les répliques si la requête est tolérante et cohérente).
-
-
PI indique les états d'attente du processeur, un AAS élevé en raison du faible nombre de requêtes
-
Remplacez le coûteux $regex par des recherches de préfixes indexés ou par un index $text.
-
Écritures par lots (insertion) pour réduire l'amplification de l'écriture.
-
Note
Testez toujours vos modifications dans un environnement inférieur (hors production) avant de les promouvoir en mode de production.