View a markdown version of this page

Abfrage läuft langsam - Amazon DocumentDB
Identifizierung — Finden Sie das ProblemUntersuchen — Informationen sammelnDiagnose — Finden Sie die UrsacheBeheben — Das Problem beheben

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Abfrage läuft langsam

Identifizierung — Finden Sie das Problem

Eine langsam laufende Abfrage ist eine, die die für Ihre Geschäftsanforderungen erwartete Ausführungszeit überschreitet. Die Definition, was eine langsame Abfrage ausmacht, ist je nach Workload unterschiedlich. Sie können langsame Abfragen anhand von Profiler-Protokollen oder Performance Insights identifizieren.

  1. Aktivieren Sie den Profiler, falls er nicht bereits aktiviert ist. Profiler-Protokolle werden CloudWatch unter der Protokollgruppe: /aws/docdb/<cluster-identifier>/profiler auf Amazon geschrieben. Verwenden Sie CloudWatch Logs Insights, um sie abzufragen.

    Beispiel für eine CloudWatch Log-Analyse-Abfrage, um die 10 langsamsten Abfragen für die Sammlung ecommerce.products abzurufen:

    
filter ns="ecommerce.products" | sort millis desc | limit 10

  2. Verwenden Sie Performance Insights, um teure Abfragen nahezu in Echtzeit zu identifizieren. Aktivieren Sie Performance Insights, falls es noch nicht aktiviert ist.

    1. Öffnen Sie die AWS Konsole, navigieren Sie zu Amazon Amazon DocumentDB, dann zu Performance Insights und wählen Sie Ihre Cluster-Instance aus.

    2. Überprüfen Sie den Zeitplan für DB-Ladevorgänge (AAS) und die häufigsten Abfragen (nach DB-Auslastung). Erweitern Sie einen Abfrage-Digest, um wörtliche untergeordnete Anweisungen anzuzeigen.

    3. Erfassen Sie die Abfragen, die analysiert werden müssen.

    Anmerkung

    Möglicherweise sind nicht alle Abfragen in Performance Insights ineffiziente oder langsame Abfragen.

Untersuchen — Informationen sammeln

  1. Der Profiler stellt den Ausführungsplan für die Abfrage und die damit verbundenen wichtigsten Kennzahlen bereit, darunter millis, nreturned und PlanSummary (Indexnutzung):

    
{
    "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"
}

    Um die COLLSCAN-Abfragen zu finden:

    
filter planSummary="COLLSCAN" | sort millis desc | limit 20

  2. Verwenden Sie Performance Insights, um Trends bei der Abfrageausführung wie Wartezeiten, Auslastung und Ressourcenauswirkungen (z. B. IOPS oder CPU pro Abfrage) in Echtzeit zu analysieren.

    Da Performance Insights den Ausführungsplan für die Abfrage nicht bereitstellt, erfassen Sie die Abfrage und führen Sie explain („executionStats“) für die Abfrage in Ihrem Amazon DocumentDB-Cluster aus:

    
db.ecommerce.products.find().explain("executionStats")

  3. Korrelieren Sie optional Profiler-Metriken mit Performance Insights-Daten (ordnen Sie z. B. hohe Millionenabfragen im Profiler den häufigsten Abfragen in Performance Insights zu).

Diagnose — Finden Sie die Ursache

In diesem Schritt diagnostizieren Sie den Abfrageplan, um mögliche Optimierungen zu identifizieren. Verwenden Sie das folgende Flow-Symptom → wahrscheinliche Ursache:

  • Symptom: PlanSummary: „COLLSCAN“

    Ursache: Fehlender oder falscher Index.

  • Symptom: Langsame Aggregation mit $group/$sort

    Ursache: Die Aggregationspipeline verarbeitet möglicherweise zu viele Daten im Speicher.

  • Symptom: hohe Latenzen, während Performance Insights DB Load gruppiert nach I/O-Wartezeiten anzeigt, obwohl Indizes verwendet werden (PlanSummary: „IXSCAN“).

    Ursache: I/O gebundene Abfragen; Indizes oder Arbeitssatz überschreiten den verfügbaren Puffercache auf der Instance.

  • Symptom: PI zeigt CPU-Wartestatus und hohe AAS aufgrund weniger Abfragen

    Ursache: CPU-bound Abfragen (komplexe Aggregationen, $regex).

  • Symptom: Viele langsame Abfragen, aber keine zeigt teure PlanSummary

    Ursache: externer Engpass (Netzwerk, Drosselung, Wartungsaufgaben, Anzahl der Abfragen).

Beheben — Das Problem beheben

Wenn Sie Fixes implementieren, validieren Sie immer mit explain („executionStats“) und überwachen Sie Performance Insights DB Load.

  1. Zusammenfassung des Plans: „COLL SCAN“

    • Erstellen Sie einen zielgerichteten Index.

      Beispiel: Für häufige Abfragen, die nach {Kategorie, Preis} filtern und nach absteigendem Preis sortieren:

      
db.products.createIndex({ category: 1, price: -1 })

  2. langsame Aggregation mit $group/$sort

    • Setzen Sie $match und $project frühzeitig ein, um zu verhindern, dass Dokumente in $group/$sort landen.

    • Begrenzen Sie die Anzahl der Felder zu Beginn der 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" } } }
])

  3. hohe Latenzen, während Performance Insights die DB-Auslastung gruppiert nach I/O-Wartezeiten anzeigt

    • Überprüfen Sie, ob BufferCacheHitRatio der Wert niedrig ist oder ob die ReadIOPS auf der Instance hoch sind. Erhöhen Sie den Instanzspeicher (aktualisieren Sie die Instanzklasse, z. B. r6g.large → r6g.xlarge) oder verwenden Sie die NVMe-Instanzklasse.

    • Reduzieren Sie den Platzbedarf im Index.

    • Fügen Sie Read Replicas hinzu, um den Leseverkehr auszulagern (verwenden Sie die ReadPreference-Einstellung, um den Datenverkehr auf Replikaten umzuleiten, wenn die Abfrage tolerant und letztendlich konsistent ist).

  4. PI zeigt CPU-Wartezustände an, hohe AAS aufgrund weniger Abfragen

    • Ersetzen Sie teure $regex durch indizierte Präfixsuchen oder $text-Index.

    • Batch-Schreibvorgänge (Einfügen), um die Schreibverstärkung zu reduzieren.

Anmerkung

Testen Sie Ihre Änderungen immer in einer niedrigeren Umgebung (außerhalb der Produktionsumgebung), bevor Sie diese Änderungen in die Produktionsumgebung übertragen.