Leistung und Ressourcenauslastung - Amazon DocumentDB
Anzeigen von Statistiken zum Einfügen, Aktualisieren und LöschenAnalysieren der Cache-LeistungFinden und Beenden von langsamen und blockierten Abfragen?Anzeigen eines Abfrageplans und Optimieren einer AbfrageWie kann ich einen Abfrageplan in elastischen Clustern sehen?Auflisten aller aktuell auf einer Instance ausgeführten OperationenErmitteln, wann eine Abfrage Fortschritte machtErmitteln, warum ein System plötzlich langsam ausgeführt wirdErmitteln der Ursache einer hohen CPU-NutzungSuchen Sie die offenen Cursor auf einer InstanceAnzeigen der aktuellen Amazon DocumentDB-Engine-VersionAnalysieren der Indexnutzung und Identifizieren ungenutzter IndizesIdentifizieren verpasster IndizesZusammenfassung nützlicher Abfragen

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.

Leistung und Ressourcenauslastung

Dieser Abschnitt enthält Fragen und Lösungen für häufig auftretende Diagnoseprobleme in Amazon DocumentDB-Bereitstellungen. Die bereitgestellten Beispiele verwenden die mongo-Shell und gelten für eine einzelne Instance. Informationen zum Suchen nach einem Instance-Endpunkt finden Sie unter Grundlegendes zu Amazon DocumentDB-Endpunkten.

Wie ermittle ich die Anzahl der Einfüge-, Aktualisierungs- und Löschvorgänge, die für meine Sammlung über die Mongo-API ausgeführt werden?

Um die Anzahl der Einfüge-, Aktualisierungs- und Löschvorgänge anzuzeigen, die für eine bestimmte Sammlung ausgeführt werden, führen Sie den folgenden Befehl für diese Sammlung aus:

db.collection.stats()

Die Ausgabe dieses Befehls beschreibt Folgendes unter seinem opCounters Feld:

  • numDocsIns – Die Anzahl der Dokumente, die in diese Sammlung eingefügt wurden. Dazu gehören Dokumente, die mit den insertMany Befehlen insert und eingefügt wurden, sowie Dokumente, die durch ein Upsert eingefügt wurden.

  • numDocsUpd – Die Anzahl der Dokumentenaktualisierungen in dieser Sammlung. Dazu gehören Dokumente, die mit den findAndModify Befehlen update und aktualisiert wurden.

  • numDocsDel – Die Anzahl der Dokumente, die aus dieser Sammlung gelöscht wurden. Dazu gehören DokumentedeleteMany, die mit den findAndModify Befehlen deleteOne, remove, und gelöscht wurden.

  • lastReset – Die Zeit, zu der diese Zähler zuletzt zurückgesetzt wurden. Die von diesem Befehl bereitgestellten Statistiken werden zurückgesetzt, wenn der Cluster gestartet/gestoppt oder die Instance hoch-/herunterskaliert wird.

Eine Beispielausgabe von , die ausgeführt wird, db.collection.stats() wird unten gezeigt.

{
    "ns" : "db.test",
    "count" : ...,
    "size" : ...,
    "avgObjSize" : ...,
    "storageSize" : ...,
    "capped" : false,
    "nindexes" : ...,
    "totalIndexSize" : ...,
    "indexSizes" : {
        "_id_" : ...,
        "x_1" : ...
    },
    "collScans" : ...,
    "idxScans" : ...,
    "opCounter" : {
        "numDocsIns" : ...,
        "numDocsUpd" : ...,
        "numDocsDel" : ...
    },
    "cacheStats" : {
        "collBlksHit" : ...,
        "collBlksRead" : ..,
        "collHitRatio" : ...,
        "idxBlksHit" : ...,
        "idxBlksRead" : ...,
        "idxHitRatio" : ...
    },
    "lastReset" : "2022-09-02 19:41:40.471473+00",
    "ok" : 1,
    "operationTime" : Timestamp(1662159707, 1)
}

Dieser Statistikbefehl sollte verwendet werden, wenn sammlungsspezifische Zähler für Einfüge-, Aktualisierungs- und Löschvorgänge über die Mongo-API angezeigt werden. Eine andere Möglichkeit, sammlungsspezifische Operationszähler anzuzeigen, besteht darin, die DML-Prüfung zu aktivieren. Die Anzahl der Einfüge-, Aktualisierungs- und Löschoperationen für alle Sammlungen in Zeitintervallen von einer Minute kann in angezeigt werdenÜberwachen von Amazon DocumentDB mit CloudWatch.

Wie analysiere ich die Cache-Leistung?

Die Analyse der Cache-Leistung kann Einblicke in die Effizienz des Datenabrufs und der Systemleistung geben und basiert darauf, wie viele Daten von der Festplatte im Vergleich zum Cache gelesen werden. Wir stellen Cache-Statistiken über die Anzahl der Cache-Treffer (Daten, die aus dem Cache gelesen werden) und Cache-Fehler (Daten, die nicht im Cache gefunden und von der Festplatte gelesen werden) bereit, um Einblicke in die Cache-Leistung zu erhalten. Die Cache-Statistiken für eine bestimmte Sammlung finden Sie, indem Sie den folgenden Befehl für diese Sammlung ausführen:

db.collection.stats()

Die Werte im cacheStats Feld in der Ausgabe dieses Befehls stellen Cache-Statistiken für die Sammlung sowie die gesamten Cache-Statistiken für die Indizes bereit, die für die Sammlung erstellt wurden. Diese Statistiken sind unten aufgeführt:

  • collBlksHit – Die Anzahl der Blöcke, die während Operationen in dieser Sammlung aus dem Cache gelesen wurden.

  • collBlksRead – Die Anzahl der Blöcke, die während Operationen in dieser Sammlung von der Festplatte gelesen wurden (Cache-Fehler).

  • collHitRatio – Die Cache-Trefferrate für diese Sammlung (100 * [collBlksHit / (collBlksHit + collBlksRead)]).

  • idxBlksHit – Die Anzahl der Blöcke, die für jeden Index, der in dieser Sammlung erstellt wurde, aus dem Cache gelesen wurden.

  • idxBlksRead – Die Anzahl der von der Festplatte gelesenen Blöcke (Cache-Fehler) für jeden Index, der in dieser Sammlung erstellt wurde.

  • idxHitRatio – Die Cache-Trefferquote für die Indizes, die in dieser Sammlung erstellt wurden (100 * [idxBlksHit / (idxBlksHit + idxBlksRead)]).

  • lastReset – Die Zeit, zu der diese Statistiken zuletzt zurückgesetzt wurden. Die von bereitgestellten Statistiken db.collection.stats() werden zurückgesetzt, wenn der Cluster gestartet/gestoppt oder die Instance hoch-/herunterskaliert wird.

Eine Aufschlüsselung der idxBlksRead Felder idxBlksHit und für jeden Index finden Sie auch mit dem indexStats Befehl . Indexspezifische Cache-Statistiken finden Sie, indem Sie den folgenden Befehl ausführen: 

db.collection.aggregate([{$indexStats:{}}]).pretty()

Für jeden Index finden Sie die folgenden Cache-Statistiken unter dem cacheStats Feld :

  • blksHit – Die Anzahl der Blöcke, die für diesen Index aus dem Cache gelesen wurden.

  • blksRead – Die Anzahl der Blöcke, die für diesen Index von der Festplatte gelesen wurden.

  • blksHitRatio – Die Cache-Trefferrate auf vier Dezimalstellen gerundet, berechnet durch 100 * [blksHit / (blksHit + blksRead)].

Wie finde und beende ich langsame und blockierte Abfragen?

Benutzerabfragen können aufgrund eines nicht optimalen Abfrageplans langsam ausgeführt oder aufgrund von Ressourcenkonflikten blockiert werden.

Zum Suchen nach Abfragen, die aufgrund eines nicht optimalen Abfrageplans verlangsamt oder aufgrund von Ressourcenkonflikten blockiert werden, verwenden Sie den Befehl currentOp. Sie können den Befehl filtern, um die Liste der relevanten Abfragen einzugrenzen. Mit der langsamen Abfrage muss opid verknüpft sein, um sie beenden zu können.

Die folgende Abfrage verwendet den Befehl currentOp, um alle Abfragen aufzulisten, die blockiert oder länger als 10 Sekunden ausgeführt werden.

db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: 
            {$or: [
                {secs_running: {$gt: 10}},
                {WaitState: {$exists: true}}]}},
        {$project: {_id:0, opid: 1, secs_running: 1}}],
    cursor: {}
});

Als Nächstes können Sie die Abfrage einschränken, um die opid von länger als 10 Sekunden ausgeführten Abfragen zu finden und diese zu beenden.

So finden und beenden Sie eine Abfrage, die länger als 10 Sekunden läuft:

  1. Suchen Sie die opid der Abfrage.

    db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: 
            {$or: 
                [{secs_running: {$gt: 10}},
                 {WaitState: {$exists: true}}]}}],
    cursor: {}
});

    Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

    {
    "waitedMS" : NumberLong(0),
    "cursor" : {
        "firstBatch" : [
            {
                "opid" : 24646,
                "secs_running" : 12 
            }
        ],
        "id" : NumberLong(0),
        "ns" : "admin.$cmd"
    },
    "ok" : 1
}

  2. Beenden Sie die Abfrage mit der Operation killOp.

    db.adminCommand({killOp: 1, op: 24646});

Wie kann ich einen Abfrageplan sehen und eine Abfrage optimieren?

Wenn eine Abfrage langsam ausgeführt wird, erfordert die Abfrageausführung möglicherweise den vollständigen Scan der Sammlung, um die relevanten Dokumente auszuwählen. Manchmal kann die Abfrage schneller ausgeführt werden, wenn geeignete Indizes erstellt werden. Mit dem Befehl explain erkennen Sie dieses Szenario und können die Felder für die Indizes auswählen.

Anmerkung

Amazon DocumentDB emuliert die MongoDB 3.6-API auf einer speziell entwickelten Datenbank-Engine, die ein verteiltes, fehlertolerantes, selbstverstärkendes Speichersystem verwendet. Daher explain() können Abfragepläne und die Ausgabe von zwischen Amazon DocumentDB und MongoDB unterschiedlich sein. Kunden, die die Kontrolle über ihren Abfrageplan wünschen, können den $hint-Operator verwenden, um die Auswahl eines bevorzugten Indexes zu erzwingen.

Führen Sie die Abfrage, die Sie verbessern möchten, unter dem Befehl explain wie folgt aus.

db.runCommand({explain: {<query document>}})

Im Folgenden finden Sie eine Beispieloperation.

db.runCommand({explain:{
    aggregate: "sample-document",
    pipeline: [{$match: {x: {$eq: 1}}}],
    cursor: {batchSize: 1}}
});

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "db.test",
        "winningPlan" : {
            "stage" : "COLLSCAN"
        }
    },
    "serverInfo" : {
        "host" : "...",
        "port" : ...,
        "version" : "..."
    },
    "ok" : 1
}

Die Ausgabe oben zeigt an, dass in der Phase $match die gesamte Sammlung gescannt werden muss, um zu prüfen, ob das Feld "x" in jedem Dokument gleich 1 ist. Wenn die Sammlung zahlreiche Dokumente enthält, wird der Scan der Sammlung sehr langsam ausgeführt. Damit ist auch die Gesamtleistung der Abfrage sehr niedrig. Das Vorhandensein von "COLLSCAN" in der Ausgabe des Befehls explain zeigt daher an, dass die Abfrageleistung durch die Erstellung geeigneter Indizes verbessert werden kann.

In diesem Beispiel prüft die Abfrage, ob das Feld "x" in allen Dokumenten gleich 1 ist. Das Erstellen eines Indexes für das Feld "x" ermöglicht der Abfrage, einen vollständigen Scan der Sammlung zu vermeiden und den Index zu verwenden, um die relevanten Dokumente schneller zurückzugeben.

Nach dem Erstellen eines Indexes für das Feld "x" sieht die explain-Ausgabe wie folgt aus.

{
    "queryPlanner" : {
         "plannerVersion" : 1,
         "namespace" : "db.test",
         "winningPlan" : {
             "stage" : "IXSCAN",
             "indexName" : "x_1",
             "direction" : "forward"
         }
    },
    "serverInfo" : {
        "host" : "...",
        "port" : ...,
        "version" : "..."
    },
    "ok" : 1
}

Das Erstellen eines Indexes für das Feld "x" ermöglicht der Stufe $match die Verwendung eines Index, um die Anzahl der Dokumente zu reduzieren, in denen das Prädikat "x = 1" ausgewertet werden muss.

Bei kleinen Sammlungen kann der Amazon DocumentDB-Abfrageprozessor wählen, keinen Index zu verwenden, wenn die Leistungssteigerungen vernachlässigbar sind.

Wie kann ich einen Abfrageplan in elastischen Clustern sehen?

Um einen Abfrageplan in elastischen Clustern zu untersuchen, verwenden Sie den explain Befehl . Im Folgenden finden Sie eine explain Beispieloperation für eine Suchabfrage, die auf eine Sharded-Sammlung abzielt:

db.runCommand(
   {
     explain: { find: "cities", filter: {"name": "Seoul"}}
   }
)
Anmerkung

Amazon DocumentDB emuliert MongoDB auf einer speziell entwickelten Datenbank-Engine. Daher explain() können Abfragepläne und die Ausgabe von zwischen Amazon DocumentDB und MongoDB unterschiedlich sein. Sie können den Abfrageplan mithilfe des -$hintOperators steuern, um die Auswahl eines bevorzugten Index zu erzwingen.

Die Ausgabe dieser Operation kann etwa wie folgt aussehen (JSON-Format):

{
  "queryPlanner" : {
    "elasticPlannerVersion" : 1,
    "winningPlan" : {
      "stage" : "SINGLE_SHARD",
      "shards" : [
        {
          "plannerVersion" : 1,
          "namespace" : "population.cities",
          "winningPlan" : {
            "stage" : "SHARD_MERGE",
            "shards" : [
              {
                "shardName" : "f2cf5cfd-fe9c-40ca-b4e5-298ca0d11111",
                "plannerVersion" : 1,
                "namespace" : "population.cities",
                "winningPlan" : {
                  "stage" : "PARTITION_MERGE",
                  "inputStages" : [
                    {
                      "stage" : "COLLSCAN",
                      "partitionCount" : 21
                    }
                  ]
                }
              },
              {
                "shardName" : "8f3f80e2-f96c-446e-8e9d-aab8c7f22222",
                "plannerVersion" : 1,
                "namespace" : "population.cities",
                "winningPlan" : {
                  "stage" : "PARTITION_MERGE",
                  "inputStages" : [
                    {
                      "stage" : "COLLSCAN",
                      "partitionCount" : 21
                    }
                  ]
                }
              },
              {
                "shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a033333",
                "plannerVersion" : 1,
                "namespace" : "population.cities",
                "winningPlan" : {
                  "stage" : "PARTITION_MERGE",
                  "inputStages" : [
                    {
                      "stage" : "COLLSCAN",
                      "partitionCount" : 22
                    }
                  ]
                }
              }
            ]
          },
          "shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a0f3fb58"
        }
      ]
    }
  },
  "serverInfo" : {
    "host" : "example-4788267630.us-east-1.docdb-elastic.amazonaws.com:27017",
    "version" : "5.0.0"
  },
  "ok" : 1,
  "operationTime" : Timestamp(1695097923, 1)
}

Die obige Ausgabe zeigt den Abfrageplan für die find Abfrage auf einem Cluster mit drei Shards. Jeder Shard hat mehrere Datenpartitionen, die unterschiedliche Eingabephasen haben können. In diesem Beispiel wird ein „COLLSCAN“ (ein Sammlungsscan) auf allen Partitionen ausgeführt, bevor die Ergebnisse in der Phase „PARTITION_MERGE“ innerhalb jedes Shards zusammengeführt werden. Die Ergebnisse für alle Shards werden dann in der Phase „SHARD_MERGE“ zusammengeführt, bevor sie zurück an den Client gesendet werden.

Wie liste ich alle laufenden Operationen für eine Instance auf?

Als Benutzer oder Primärbenutzer möchten Sie häufig alle aktuellen Operationen auflisten, die auf einer Instance ausgeführt werden, um Diagnose- und Fehlerbehebungszwecke zu verwenden. (Weitere Informationen zum Verwalten von Benutzern finden Sie unter Amazon-DocumentDB-Benutzer.)

Mit der mongo Shell können Sie die folgende Abfrage verwenden, um alle laufenden Operationen auf einer Amazon DocumentDB-Instance aufzulisten.

db.adminCommand({currentOp: 1, $all: 1});

Die Abfrage gibt die vollständige Liste aller Benutzerabfragen und internen Systemaufgaben zurück, die zurzeit auf der Instance ausgeführt werden.

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

{
    "inprog" : [
        {
            "desc" : "INTERNAL"
        },
        {
            "desc" : "TTLMonitor",
            "active" : false
        },
        {
            "client" : ...,
            "desc" : "Conn",
            "active" : true,
            "killPending" : false,
            "opid" : 195,
            "ns" : "admin.$cmd",
            "command" : {
                "currentOp" : 1,
                "$all" : 1
            },
            "op" : "command",
            "$db" : "admin",
            "secs_running" : 0,
            "microsecs_running" : NumberLong(68),
            "clientMetaData" : {
            "application" : {
                "name" : "MongoDB Shell"
            },
            "driver" : {
                ...
            },
            "os" : {
                ...
            }
          }
       },
       {
          "desc": "GARBAGE_COLLECTION",
          "garbageCollection": {
             "databaseName": "testdb",
             "collectionName": "testCollectionA"
          },
          "secs_running": 3,
          "microsecs_running": NumberLong(3123456)
       },
       {
          "desc": "GARBAGE_COLLECTION",
          "garbageCollection": {
             "databaseName": "testdb",
             "collectionName": "testCollectionB"
          },
          "secs_running": 4,
          "microsecs_running": NumberLong(4123456)
       }
    ],
    "ok" : 1
}

Die folgenden Werte sind gültige Werte für das Feld "desc":

  • INTERNAL – Interne Systemaufgaben wie die Cursor-Bereinigungs- oder veraltete Benutzerbereinigungsaufgaben.

  • TTLMonitor – Der TTL-Monitor-Thread (Time to Live). Der Ausführungsstatus wird im Feld "active" dargestellt.

  • GARBAGE_COLLECTION – Der interne Garbage Collector-Thread.

  • CONN – Die Benutzerabfrage.

  • CURSOR – Die Operation ist ein inaktiver Cursor, der darauf wartet, dass der Benutzer den Befehl „getMore“ aufruft, um den nächsten Ergebnisstapel zu erhalten. In diesem Zustand verbraucht der Cursor Speicher, verbraucht jedoch keine Rechenleistung.

In der obigen Ausgabe werden auch alle Benutzerabfragen im System aufgeführt. Jede Benutzerabfrage wird im Kontext einer Datenbank und einer Sammlung ausgeführt. Die Kombination dieser beiden Komponenten wird als Namespace bezeichnet. Der Namespace jeder Benutzerabfrage ist im Feld "ns" verfügbar.

Manchmal müssen Sie alle Benutzerabfragen auflisten, die in einem bestimmten Namespace ausgeführt werden. Daher muss die vorherige Ausgabe anhand des Felds "ns" gefiltert werden. Im Folgenden finden Sie eine Beispielabfrage für eine gefilterte Ausgabe. Die Abfrage listet alle Benutzerabfragen auf, die zurzeit in der Datenbank "db" und in der Sammlung "test" ausgeführt werden (d. h. im Namespace "db.test").

db.adminCommand({aggregate: 1,
    pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
               {$match: {ns: {$eq: "db.test"}}}],
    cursor: {}
});

Als primärer Benutzer des Systems können Sie Abfragen aller Benutzer und auch aller internen Systemaufgaben sehen. Alle anderen Benutzer können nur ihre jeweiligen Abfragen anzeigen.

Wenn die Gesamtzahl der Abfragen und internen Systemaufgaben die Standard-Batch-Cursor-Größe überschreitet, generiert die mongo-Shell automatisch das Iterator-Objekt 'it', um den Rest der Ergebnisse anzuzeigen. Führen Sie den Befehl 'it' so lange aus, bis alle Ergebnisse angezeigt wurden.

Woher weiß ich, wann eine Abfrage ausgeführt wird?

Benutzerabfragen können aufgrund eines nicht optimalen Abfrageplans langsam ausgeführt oder aufgrund von Ressourcenkonflikten blockiert werden. Das Debuggen solcher Abfragen ist ein mehrstufiger Prozess, in dem möglicherweise mehrmals dieselben Schritte ausgeführt werden müssen.

Im ersten Debugging-Schritt werden alle langsamen oder blockierten Abfragen aufgeführt. Die folgende Abfrage listet alle Benutzerabfragen auf, die länger als 10 Sekunden ausgeführt wurden oder auf Ressourcen warten.

db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {}},
                            {$match: {$or: [{secs_running: {$gt: 10}},
                                            {WaitState: {$exists: true}}]}},
                            {$project: {_id:0,
                                        opid: 1,
                                        secs_running: 1,
                                        WaitState: 1,
                                        blockedOn: 1,
                                        command: 1}}],
                 cursor: {}
                });

Wiederholen Sie die vorherige Abfrage regelmäßig, um zu ermitteln, ob sich die Liste der Abfragen ändert, und die langsamen oder blockierten Abfragen zu identifizieren.

Wenn das Ausgabedokument der betreffenden Abfrage das Feld WaitState enthält, zeigt dies an, dass die Abfrage aufgrund von Ressourcenkonflikten langsam ist oder blockiert wird. Die Ressourcenkonflikte könnten auf E/A-Vorgänge, interne Systemaufgaben oder die Abfragen anderer Benutzer zurückgehen.

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

{
    "waitedMS" : NumberLong(0),
    "cursor" : {
        "firstBatch" : [
            {
                "opid" : 201,
                "command" : {
                    "aggregate" : ...
                },
                "secs_running" : 208,
                "WaitState" : "IO"
            }
        ],
        "id" : NumberLong(0),
        "ns" : "admin.$cmd"
    },
    "ok" : 1
}

Die E/A-Schnittstelle kann einen Engpass darstellen, wenn zahlreiche Abfragen in verschiedenen Sammlungen auf derselben Instance gleichzeitig ausgeführt werden oder die Instance zu klein für den Datensatz ist, auf dem die Abfrage ausgeführt wird. Wenn es sich bei den Abfragen um schreibgeschützte Abfragen handelt, können Sie der eben beschriebenen Situation durch Aufteilung der Abfragen für die einzelnen Sammlungen auf separate Replikate abhelfen. Wenn in verschiedenen Sammlungen gleichzeitig Updates ausgeführt werden oder die Instance zu klein für den Datensatz ist, können Sie die Instance aufwärts skalieren.

Wenn der Ressourcenkonflikt auf Abfragen anderer Benutzer zurückzuführen ist, zeigt das Feld "blockedOn" im Ausgabedokument die "opid" der Abfrage an, die sich auf die Abfrage auswirkt. Folgen Sie mithilfe der "opid" der Kette der Felder "WaitState" und "blockedOn" aller Abfragen, um die Abfrage an der Ende der Kette zu finden.

Wenn es sich bei der Aufgabe am Ende der Kette um eine interne Aufgabe handelt, kann das Problem nur behoben werden, indem die Abfrage beendet und später erneut ausgeführt wird.

Im Folgenden finden Sie eine Beispielausgabe, in der die Suchabfrage auf einer Sammlungssperre blockiert wird, die im Besitz einer anderen Aufgabe ist.

{
    "inprog" : [
        {
            "client" : "...",
            "desc" : "Conn",
            "active" : true,
            "killPending" : false,
            "opid" : 75,
            "ns" : "...",
            "command" : {
                "find" : "...",
                "filter" : {

                }
            },
            "op" : "query",
            "$db" : "test",
            "secs_running" : 9,
            "microsecs_running" : NumberLong(9449440),
            "threadId" : 24773,
            "clientMetaData" : {
                "application" : {
                   "name" : "MongoDB Shell"
                },
                "driver" : {
                    ...
                },
                "os" : {
                    ...
                }
            },
            "WaitState" : "CollectionLock",
            "blockedOn" : "INTERNAL"
        },
        {
            "desc" : "INTERNAL"
        },
        {
            "client" : "...",
            ...
            "command" : {
                "currentOp" : 1
            },
            ...
        }
    ],
    "ok" : 1
}

Wenn "WaitState" die Werte "Latch", "SystemLock", "BufferLock", "BackgroundActivity" oder "Other" hat, wird der Ressourcenkonflikt von internen Systemaufgaben verursacht. Wenn die Situation lange andauert, besteht die einzige Abhilfe darin, die Abfrage zu beenden und später erneut auszuführen.

Wie stelle ich fest, warum ein System plötzlich langsam ausgeführt wird?

Im Folgenden finden Sie einige häufige Gründe für die Verlangsamung von Systemen:

  • Übermäßige Ressourcenkonflikte zwischen gleichzeitigen Abfragen

  • Zunahme der Anzahl der aktiven gleichzeitigen Abfragen im Laufe der Zeit

  • Interne Systemaufgaben wie "GARBAGE_COLLECTION"

Wenn Sie die Systemnutzung im Laufe der Zeit überwachen möchten, führen Sie in regelmäßigen Abständen die folgende "currentOp"-Abfrage aus, und geben Sie die Ergebnisse in einem externen Speicher aus. Die Abfrage zählt die Anzahl der Abfragen und Operationen in jedem Namespace im System. Sie können anschließend die Systemnutzungsergebnisse analysieren, um die Systemlast zu verstehen und entsprechende Maßnahmen zu ergreifen.

db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
                            {$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
                 cursor: {}
                });

Diese Abfrage gibt eine Aggregation aller in den einzelnen Namespaces ausgeführten Abfragen, alle internen Systemaufgaben und die eindeutige Anzahl der Wartezustände (wenn vorhanden) pro Namespace zurück.

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

{
    "waitedMS" : NumberLong(0),
    "cursor" : {
        "firstBatch" : [
            {
                "_id" : {
                    "desc" : "Conn",
                    "ns" : "db.test",
                    "WaitState" : "CollectionLock"
                },
               "count" : 2
            },
            {
                "_id" : {
                    "desc" : "Conn",
                    "ns" : "admin.$cmd"
                },
                "count" : 1
            },
            {
                "_id" : {
                    "desc" : "TTLMonitor"
                },
                "count" : 1
            }
        ],
        "id" : NumberLong(0),
        "ns" : "admin.$cmd"
    },
    "ok" : 1
}

In der oben gezeigten Ausgabe werden zwei Benutzerabfragen im Namespace "db.test" durch eine Sammlungssperre blockiert: 1 Abfrage in Namespace "admin.$cmd" und eine interne "TTLMonitor"-Aufgabe.

Wenn die Ausgabe viele Abfragen mit blockierenden Wartezuständen anzeigt, finden Sie Informationen unter Wie finde und beende ich langsame und blockierte Abfragen?.

Wie ermittle ich die Ursache für eine hohe CPU-Auslastung auf einer oder mehreren Cluster-Instances?

In den folgenden Abschnitten finden Sie Informationen, die Ihnen möglicherweise helfen, die Ursache für die hohe CPU-Nutzung einer Instance zu ermitteln. Die Ergebnisse sind vom Workload abhängig.

Abhängig vom Grund für die hohe CPU-Nutzung Ihrer Instance können Sie einen oder mehrere der folgenden Schritte ausführen.

  • Wenn die primäre Instance eine hohe CPU-Nutzung aufweist, die Replikat-Instances jedoch nicht, sollten Sie den Datenverkehr für Lesevorgänge über die Client-Leseeinstellungen auf mehrere Replikate verteilen (z. B. secondaryPreferred). Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Amazon DocumentDB als Replikatsatz.

    Die Verwendung von Replikaten für Lesevorgänge kann zu einer besseren Nutzung der Cluster-Ressourcen führen, da die primäre Instance eine größere Menge an Schreibdatenverkehr verarbeiten kann. Lesevorgänge aus -Replikaten sind Eventually Consistent.

  • Wenn die hohe CPU-Nutzung durch Schreib-Workloads verursacht wird, können Sie durch die Skalierung der Cluster-Instances auf einen größeren Instance-Typ die Anzahl der CPU-Kerne erhöhen, die für den Workload verfügbar sind. Weitere Informationen finden Sie unter Instances und Instance-Klassen-Spezifikationen.

  • Wenn alle Cluster-Instances eine hohe CPU-Nutzung aufweisen und der Workload Replikate für Lesevorgänge verwendet, erhöht das Hinzufügen weiterer Replikate zum Cluster die Zahl der für Lesevorgänge verfügbaren Ressourcen. Weitere Informationen finden Sie unter Hinzufügen einer Amazon DocumentDB-Instance zu einem Cluster.

Wie ermittle ich die offenen Cursor auf einer Instance?

Wenn Sie mit einer Amazon DocumentDB-Instance verbunden sind, können Sie den Befehl verwenden, db.runCommand("listCursors") um die offenen Cursor auf dieser Instance aufzulisten. Je nach Instance-Typ sind bis zu 4 560 aktive Cursors auf einer bestimmten Amazon DocumentDB-Instance geöffnet. Es wird allgemein empfohlen, Cursor zu schließen, die nicht mehr verwendet werden, da Cursor Ressourcen auf einer Instance verwenden und eine Obergrenze haben. Spezifische Limits finden Sie unter Amazon DocumentDB DocumentDB-Kontingente und -Beschränkungen .

db.runCommand("listCursors")

Wie ermittle ich die aktuelle Version der Amazon DocumentDB-Engine?

Führen Sie den folgenden Befehl aus, um Ihre aktuelle Amazon DocumentDB-Engine-Version zu ermitteln.

db.runCommand({getEngineVersion: 1})

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

{ "engineVersion" : "2.x.x", "ok" : 1 }
Anmerkung

Die Engine-Version für Amazon DocumentDB 3.6 ist 1.x.x und die Engine-Version für Amazon DocumentDB 4.0 ist 2.x.x.

Wie analysiere ich die Indexnutzung und identifiziere ungenutzte Indizes?

Zum Identifizieren der Indizes für eine bestimmte Sammlung führen Sie den folgenden Befehl aus:

db.collection.getIndexes()

Um zu analysieren, wie viele Indizes bei Operationen verwendet werden, die an den Sammlungen ausgeführt werden, können die indexStats Befehle collStats und verwendet werden. Führen Sie den folgenden Befehl aus, um die Gesamtzahl der Scans anzuzeigen, die mit Indizes (Indexscans) im Vergleich zur Anzahl der Scans ohne Index (Sammlungsscans) durchgeführt wurden: 

db.collection.stats()

Die Ausgabe für diesen Befehl enthält die folgenden Werte:

  • idxScans – Die Anzahl der Scans, die mit einem Index für diese Sammlung durchgeführt wurden.

  • collScans – Die Anzahl der Scans, die für diese Sammlung ohne Verwendung eines Index durchgeführt wurden. Diese Scans hätten dazu geführt, dass die Dokumente in der Sammlung nacheinander betrachtet wurden.

  • lastReset – Die Zeit, zu der diese Zähler zuletzt zurückgesetzt wurden. Die von diesem Befehl bereitgestellten Statistiken werden zurückgesetzt, wenn der Cluster gestartet/gestoppt oder die Instance hoch-/herunterskaliert wird.

Eine Aufschlüsselung der verwendeten Indexe finden Sie in der Ausgabe des folgenden Befehls. Es hat sich bewährt, regelmäßig ungenutzte Indizes zu identifizieren und zu entfernen, um die Leistung zu verbessern und die Kosten zu senken, da unnötige Rechen-, Speicher- und E/A-Operationen vermieden werden, die zur Wartung der Indizes verwendet werden.

db.collection.aggregate([{$indexStats:{}}]).pretty()

Die Ausgabe dieses Befehls liefert die folgenden Werte für jeden Index, der in der Sammlung erstellt wurde:

  • ops – Die Anzahl der Operationen, die den Index verwendet haben. Wenn Ihre Workload über einen ausreichend langen Zeitraum ausgeführt wurde und Sie sicher sind, dass sich Ihre Workload in einem konstanten Zustand befindet, würde ein ops-Wert von Null anzeigen, dass der Index überhaupt nicht verwendet wird.

  • numDocsRead – Die Anzahl der Dokumente, die während Operationen mit diesem Index gelesen wurden.

  • since – Die Zeit, seit Amazon DocumentDB mit der Erfassung von Statistiken zur Indexnutzung begonnen hat, was in der Regel der Wert seit dem letzten Neustart oder der letzten Wartungsaktion der Datenbank ist.

  • size – Die Größe dieses Index in Byte.

Das folgende Beispiel ist eine Beispielausgabe der Ausführung des obigen Befehls:

{
    "name" : "_id_",
    "key" : {
        "_id" : 1
    },
    "host" : "example-host.com:12345",
    "size" : NumberLong(...),
    "accesses" : {
        "ops" : NumberLong(...),
        "docsRead" : NumberLong(...),
        "since" : ISODate("...")
    },
    "cacheStats" : {
        "blksRead" : NumberLong(...),
        "blksHit" : NumberLong(...),
        "hitRatio" : ...
    }
}
{
    "name" : "x_1",
    "key" : {
        "x" : 1
    },
    "host" : "example-host.com:12345",
    "size" : NumberLong(...),
    "accesses" : {
        "ops" : NumberLong(...),
        "docsRead" : NumberLong(...),
        "since" : ISODate("...")
    },
    "cacheStats" : {
        "blksRead" : NumberLong(...),
        "blksHit" : NumberLong(...),
        "hitRatio" : ...
    }
}

Um die Gesamtindexgröße für eine Sammlung zu ermitteln, führen Sie den folgenden Befehl aus:

db.collection.stats()

Führen Sie den folgenden Befehl aus, um einen nicht verwendeten Index zu löschen:

db.collection.dropIndex("indexName")

Wie erkenne ich fehlende Indizes?

Sie können den Amazon DocumentDB-Profiler verwenden, um langsame Abfragen zu protokollieren. Eine Abfrage, die wiederholt im Protokoll über langsame Abfragen erscheint, kann darauf hinweisen, dass ein zusätzlicher Index erforderlich ist, um diese Abfrageleistung zu verbessern.

Sie können Möglichkeiten für hilfreiche Indizes identifizieren, indem Sie nach lang laufenden Abfragen suchen, die eine oder mehrere Stufen haben und mindestens eine COLLSCAN-Stufe durchführen, d.h. in der Abfragephase muss jedes Dokument in der Sammlung gelesen werden, um eine Antwort auf die Abfrage bereitzustellen.

Das folgende Beispiel zeigt eine Abfrage zu einer Sammlung von Taxifahrten, die auf einer großen Sammlung ausgeführt wurden.

db.rides.count({"fare.totalAmount":{$gt:10.0}}))

Um dieses Beispiel auszuführen, musste die Abfrage einen Sammlungsscan durchführen (d. h. jedes einzelne Dokument in der Sammlung lesen), da es keinen Index für das fare.totalAmount-Feld gibt. Die Ausgabe vom Amazon DocumentDB-Profiler für diese Abfrage sieht etwa wie folgt aus: 

{
    ...
    "cursorExhausted": true,
    "nreturned": 0, 
    "responseLength": 0,
    "protocol": "op_query",
    "millis": 300679,
    "planSummary": "COLLSCAN",
    "execStats": {
        "stage": "COLLSCAN",
        "nReturned": "0",
        "executionTimeMillisEstimate": "300678.042"
    },
    "client": "172.31.5.63:53878",
    "appName": "MongoDB Shell",
    "user": "example"
}

Um die Abfrage in diesem Beispiel zu beschleunigen, möchten Sie einen Index auf fare.totalAmount erstellen, wie unten gezeigt.

db.rides.createIndex( {"fare.totalAmount": 1}, {background: true} )
Anmerkung

Indizes, die im Vordergrund erstellt werden (d. h. wenn die Option {background:true} beim Erstellen des Index nicht angegeben wurde), erhalten eine exklusive Schreibsperre, die Anwendungen daran hindert, Daten so lange in die Sammlung zu schreiben, bis der Indexaufbau abgeschlossen ist. Beachten Sie diese mögliche Auswirkung beim Erstellen von Indizes für Produktions-Cluster. Beim Erstellen von Indizes empfehlen wir die Einstellung {background:true}.

Im Allgemeinen möchten Sie Indizes für Felder mit hoher Kardinalität erstellen (z. B. eine große Anzahl eindeutiger Werte). Das Erstellen eines Index für ein Feld mit geringer Kardinalität kann zu einem großen Index führen, der nicht verwendet wird. Der Amazon DocumentDB-Abfrageoptimierer berücksichtigt die Gesamtgröße der Sammlung und die Selektivität der Indizes beim Erstellen eines Abfrageplans. Manchmal wird der Abfrageprozessor einen COLLSCAN auswählen, selbst wenn ein Index vorhanden ist. Dies geschieht, wenn der Abfrageprozessor schätzt, dass die Verwendung des Index keinen Leistungsvorteil gegenüber dem Scannen der gesamten Sammlung bringt. Wenn Sie den Abfrageprozessor zwingen möchten, einen bestimmten Index zu verwenden, können Sie den hint()-Operator wie unten gezeigt verwenden.

db.collection.find().hint("indexName")

Zusammenfassung nützlicher Abfragen

Die folgenden Abfragen können für die Überwachung der Leistung und Ressourcenauslastung in Amazon DocumentDB nützlich sein.

  • Verwenden Sie den folgenden Befehl, um Statistiken zu einer bestimmten Sammlung anzuzeigen, einschließlich Operationszähler, Cache-Statistiken, Zugriffsstatistiken und Größenstatistiken:

    db.collection.stats()

  • Verwenden Sie den folgenden Befehl, um Statistiken zu jedem Index anzuzeigen, der für eine Sammlung erstellt wurde, einschließlich der Größe des Index, indexspezifischer Cache-Statistiken und Indexnutzungsstatistiken:

    db.collection.aggregate([{$indexStats:{}}]).pretty()

  • Verwenden Sie die folgende Abfrage, um alle Aktivitäten aufzulisten.

    db.adminCommand({currentOp: 1, $all: 1});

  • Der folgende Code listet alle langsamen oder blockierten Abfragen auf.

    db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {}},
                            {$match: {$or: [{secs_running: {$gt: 10}},
                                            {WaitState: {$exists: true}}]}},
                            {$project: {_id:0,
                                        opid: 1,
                                        secs_running: 1,
                                        WaitState: 1,
                                        blockedOn: 1,
                                        command: 1}}],
                 cursor: {}
                });

  • Der folgende Code beendet eine Abfrage.

    db.adminCommand({killOp: 1, op: <opid of running or blocked query>});

  • Verwenden Sie den folgenden Code, um eine aggregierte Ansicht des Systemstatus zu erhalten.

    db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
                            {$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
                 cursor: {}
                });