Problembehandlung bei Leistung und Ressourcenauslastung

Dieser Abschnitt enthält Fragen und Lösungen für häufig auftretende Diagnoseprobleme bei 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 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 wurden?

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

db.collection.stats()

Die Ausgabe dieses Befehls beschreibt in seinem opCounters Feld Folgendes:

Ein Beispiel für die Ausgabe von running db.collection.stats() ist unten dargestellt.

{
    "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 Betriebszähler anzuzeigen, besteht darin, das DML-Auditing zu aktivieren. Die Anzahl der Einfüge-, Aktualisierungs- und Löschvorgänge für alle Sammlungen in Zeitintervallen von einer Minute kann unter angezeigt werden. Überwachung von Amazon DocumentDB mit CloudWatch

Wie analysiere ich die Cache-Leistung?

Die Analyse der Cache-Leistung kann Aufschluss über die Effizienz des Datenabrufs und die Systemleistung geben. Sie basiert darauf, wie viele Daten von der Festplatte gelesen werden und wie viele Daten vom Cache gelesen werden. Wir stellen Cache-Statistiken zur Anzahl der Cache-Treffer (aus dem Cache gelesene Daten) und Cache-Fehlschläge (Daten, die nicht im Cache gefunden und von der Festplatte gelesen wurden) zur Verfügung, um einen Einblick in die Cache-Leistung zu geben. Die Cache-Statistiken für eine bestimmte Sammlung können gefunden werden, indem Sie den folgenden Befehl für diese Sammlung ausführen:

db.collection.stats()

Die Werte in dem cacheStats Feld in der Ausgabe dieses Befehls liefern Cachestatistiken für die Sammlung sowie die gesamten Cachestatistiken für die Indizes, die für die Sammlung erstellt wurden. Diese Statistiken sind unten aufgeführt:

Eine Aufschlüsselung der idxBlksRead Felder idxBlksHit und für jeden Index kann auch mithilfe des indexStats Befehls abgerufen werden. Indexspezifische Cachestatistiken können mit dem folgenden Befehl abgerufen werden:

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

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

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.

Wie kann ich einen Abfrageplan einsehen 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.

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 sich der Amazon DocumentDB-Abfrageprozessor dafür entscheiden, keinen Index zu verwenden, wenn die Leistungssteigerungen vernachlässigbar sind.

Wie kann ich einen Abfrageplan in elastischen Clustern sehen?

Verwenden Sie den explain Befehl, um einen Abfrageplan in elastischen Clustern zu untersuchen. Im Folgenden finden Sie ein Beispiel für einen explain Vorgang mit einer Suchabfrage, die auf eine gemeinsame Sammlung abzielt:

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

Die Ausgabe dieser Operation könnte 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 vorherige Ausgabe zeigt den Abfrageplan für die find Abfrage in einem Cluster mit drei Shards. Jeder Shard hat mehrere Datenpartitionen, die unterschiedliche Eingabeschritte haben können. In diesem Beispiel wird ein „COLLSCAN“ (ein Sammlungsscan) auf allen Partitionen ausgeführt, bevor die Ergebnisse in der“ PARTITION_MERGE „-Stufe innerhalb jedes Shards zusammengeführt werden. Die Ergebnisse der Shards werden dann in der“ SHARD_MERGE „-Phase zusammengeführt, bevor sie an den Client zurückgesendet werden.

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

Als Benutzer oder Hauptbenutzer möchten Sie häufig alle aktuellen Vorgänge, die auf einer Instance ausgeführt werden, zu Diagnose- und Fehlerbehebungszwecken auflisten. (Weitere Informationen zum Verwalten von Benutzern finden Sie unter Verwaltung von Amazon DocumentDB-Benutzern.)

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":

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 Hauptbenutzer des Systems können Sie Abfragen aller Benutzer und auch alle 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 Anfrage Fortschritte macht?

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. Der Ressourcenkonflikt kann entweder auf I/O interne Systemaufgaben oder andere Benutzerabfragen zurückzuführen sein.

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
}

I/O kann ein Engpass sein, wenn viele Abfragen in verschiedenen Sammlungen gleichzeitig auf derselben Instanz ausgeführt werden oder wenn die Instanzgröße für den Datensatz, auf dem die Abfrage ausgeführt wird, zu klein ist. 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 läuft?

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

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.

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 geöffneten Cursor auf dieser Instance aufzulisten. In einer bestimmten Amazon DocumentDB-Instance gibt es je nach Instance-Typ ein Kontingent von bis zu 4.560 aktiven Cursorn, die zu einem bestimmten Zeitpunkt geöffnet sind. Schließen Sie Cursor, die nicht mehr verwendet werden, da Cursor Ressourcen auf einer Instance nutzen. Weitere Informationen finden Sie unter Amazon DocumentDB-Kontingente.

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 }

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 an den Sammlungen verwendet werden, können die indexStats Befehle collStats und verwendet werden. Führen Sie den folgenden Befehl aus, um die Gesamtzahl der mithilfe von Indizes (Indexscans) durchgeführten Scans im Vergleich zur Anzahl der ohne Index durchgeführten Scans (Sammlungsscans) anzuzeigen:

db.collection.stats()

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

Eine Aufschlüsselung darüber, wie stark jeder Index verwendet wird, finden Sie in der Ausgabe des folgenden Befehls. Es hat sich bewährt, ungenutzte Indizes regelmäßig zu identifizieren und zu entfernen, um die Leistung zu verbessern und die Kosten zu senken, da auf diese Weise unnötige Rechenleistung, Speicherung und I/Os Verwaltung der Indizes vermieden werden.

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

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

Das folgende Beispiel ist eine Beispielausgabe bei 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 identifiziere 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 Abfragen mit langer Laufzeit suchen, die eine oder mehrere Stufen enthalten, die mindestens eine COLLSCAN Phase ausführen. Das bedeutet, dass die Abfragephase jedes Dokument in der Sammlung lesen muss, um eine Antwort auf die Abfrage zu geben.

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 des Amazon DocumentDB-Profilers für diese Abfrage sieht in 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} )

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 bei der Erstellung eines Abfrageplans die Gesamtgröße der Sammlung und die Selektivität der Indizes. 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")

Wie stelle ich fest, dass die Datenbanksammlung überfüllt ist?

Eine Aufblähung der Sammlung tritt auf, wenn die Größe einer Sammlung aufgrund der Anhäufung toter oder veralteter Dokumente oder der Fragmentierung innerhalb von Datenbankseiten zunimmt. Der angegebene Prozentsatz gibt den Speicherplatz an Dokumenten an, der für zukünftige Dokumente genutzt werden kann. Diese Überlastung verbraucht Speicherplatz sowohl im Puffercache als auch im Speicher. Um die Überlastung zu vermeiden, müssen Sammlungen entweder über dump/restore oder mithilfe eines Migrations-Loopbacks und Switchovers während eines Wartungsfensters neu geladen werden.

db.runCommand({collStats:'coll'})

{
        "ns" : "test.coll",
        "count" : 7500,
        "size" : 23250,
        "avgObjSize" : 31,
        "storageSize" : 106496,
        "unusedStorageSize" : {
                "unusedBytes" : 16384,
                "unusedPercent" : 25.12
        },
        "compression" : {
                "enable" : false
        },
        "capped" : false,
        "nindexes" : 1,
        "totalIndexSize" : 57344,
        "indexSizes" : {
                "_id_" : 57344
        },
        "collScans" : 4,
        "idxScans" : 10000,
        "opCounter" : {
                "numDocsIns" : 1000,
                "numDocsUpd" : 0,
                "numDocsDel" : 250
        },
        "cacheStats" : {
                "collBlksHit" : 3570,
                "collBlksRead" : 8,
                "collHitRatio" : 99.7765,
                "idxBlksHit" : 12293,
                "idxBlksRead" : 6,
                "idxHitRatio" : 99.9513
        },
        "lastReset" : "2024-12-18 00:30:21.552019+00",
        "ok" : 1,
        "operationTime" : Timestamp(1734632375, 1)
}

Zusammenfassung nützlicher Abfragen

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