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.
# Problembehebung bei Amazon DocumentDB
Die folgenden Abschnitte enthalten Informationen zur Behebung von Problemen, die bei der Verwendung von Amazon DocumentDB (mit MongoDB-Kompatibilität) auftreten können.
**Topics**
+ [Verbindungsprobleme](troubleshooting.connecting.md)
+ [Indizes](troubleshooting.index-creation.md)
+ [Leistung und Ressourcennutzung](user_diagnostics.md)
+ [Müllabfuhr](garbage-collection.md)
# Fehlerbehebung bei Verbindungsproblemen
Haben Sie Probleme beim Herstellen einer Verbindung? Im Folgenden finden Sie einige gängige Szenarien und wie Sie sie lösen können.
**Topics**
+ [Es kann keine Verbindung zu einem Amazon DocumentDB DocumentDB-Endpunkt hergestellt werden](#troubleshooting-connecting)
+ [Testen einer Verbindung zu einer Amazon DocumentDB DocumentDB-Instance](#troubleshooting.testing-connection)
+ [Verbindung zu einem ungültigen Endpunkt herstellen](#troubleshooting.invalid-endpoint)
+ [Die Treiberkonfiguration wirkt sich auf die Anzahl der Verbindungen aus](#troubleshooting.driver.config)
## Es kann keine Verbindung zu einem Amazon DocumentDB DocumentDB-Endpunkt hergestellt werden
Wenn Sie versuchen, eine Verbindung zu Amazon DocumentDB herzustellen, wird die folgende Fehlermeldung am häufigsten angezeigt.
```
connecting to: mongodb://docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-
1.docdb.amazonaws.com:27017/
2018-11-14T14:33:46.451-0800 W NETWORK [thread1] Failed to connect to
172.31.91.193:27017 after 5000ms milliseconds, giving up.
2018-11-14T14:33:46.452-0800 E QUERY [thread1] Error: couldn't connect to server
docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-1.docdb.amazonaws.com:27017,
connection attempt failed :
connect@src/mongo/shell/mongo.js:237:13
@(connect):1:6
exception: connect failed
```
Diese Fehlermeldung bedeutet in der Regel, dass Ihr Client (in diesem Beispiel die Mongo-Shell) nicht auf den Amazon DocumentDB DocumentDB-Endpunkt zugreifen kann. Dies kann aus verschiedenen Gründen der Fall sein:
**Topics**
+ [Verbindung von öffentlichen Endpunkten aus herstellen](#troubleshooting.cannot-connect.public-endpoints)
+ [Regionsübergreifende Verbindungen](#troubleshooting.cannot-connect.different-regions)
+ [Verbindung von einem anderen Amazon aus herstellen VPCs](#troubleshooting.cannot-connect.different-vpcs)
+ [Die Sicherheitsgruppe blockiert eingehende Verbindungen](#troubleshooting.cannot-connect.inbound-not-allowed)
+ [Problem mit den Leseeinstellungen des Java-Mongo-Treibers](#troubleshooting-cannot-connect-java-mongo-issue)
### Verbindung von öffentlichen Endpunkten aus herstellen
**Sie versuchen, direkt von Ihrem Laptop oder Ihrem lokalen Entwicklungscomputer aus eine Verbindung zu einem Amazon DocumentDB-Cluster herzustellen.**
Der Versuch, direkt von einem öffentlichen Endpunkt aus, z. B. Ihrem Laptop oder Ihrem lokalen Entwicklungscomputer, eine Verbindung zu einem Amazon DocumentDB-Cluster herzustellen, schlägt fehl. Amazon DocumentDB ist nur für Virtual Private Cloud (VPC) verfügbar und unterstützt derzeit keine öffentlichen Endpunkte. Daher können Sie von Ihrem Laptop oder Ihrer lokalen Entwicklungsumgebung außerhalb Ihrer VPC keine direkte Verbindung zu Ihrem Amazon DocumentDB-Cluster herstellen.
Um von außerhalb einer Amazon VPC eine Verbindung zu einem Amazon DocumentDB-Cluster herzustellen, können Sie einen SSH-Tunnel verwenden. Weitere Informationen finden Sie unter [Von außerhalb einer Amazon VPC eine Verbindung zu einem Amazon DocumentDB-Cluster herstellen](connect-from-outside-a-vpc.md). Wenn sich Ihre Entwicklungsumgebung in einer anderen Amazon VPC befindet, können Sie außerdem VPC Peering verwenden und von einer anderen Amazon VPC in derselben Region oder einer anderen Region aus eine Verbindung zu Ihrem Amazon DocumentDB-Cluster herstellen.
### Regionsübergreifende Verbindungen
**Sie versuchen, eine Verbindung zu einem Amazon DocumentDB-Cluster in einer anderen Region herzustellen.**
Wenn Sie versuchen, von einer Amazon EC2-Instance in einer anderen Region als der Region des Clusters aus eine Verbindung zu einem Amazon DocumentDB-Cluster herzustellen, z. B. wenn Sie versuchen, von der Region USA West (Oregon) (us-west-2) aus eine Verbindung zu einem Cluster in der Region USA Ost (Nord-Virginia) (us-east-1) herzustellen, schlägt die Verbindung fehl.
Führen Sie den folgenden Befehl aus, um die Region Ihres Amazon DocumentDB-Clusters zu überprüfen. Die Region ist im Endpunkt.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].Endpoint'
```
Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus.
```
[
"sample-cluster.node.us-east-1.docdb.amazonaws.com"
]
```
Um die Region Ihrer EC2-Instance zu überprüfen, führen Sie den folgenden Befehl aus.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].Placement.AvailabilityZone'
```
Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus.
```
[
[
"us-east-1a"
]
]
```
### Verbindung von einem anderen Amazon aus herstellen VPCs
**Sie versuchen, von einer VPC aus eine Verbindung zu einem Amazon DocumentDB-Cluster herzustellen, die sich von der Amazon VPC unterscheidet, auf der Ihr Cluster bereitgestellt ist.**
Wenn sich sowohl Ihr Amazon DocumentDB-Cluster als auch Ihre Amazon EC2 EC2-Instance in derselben AWS-Region, aber nicht in derselben Amazon VPC befinden, können Sie keine direkte Verbindung zu Ihrem Amazon DocumentDB-Cluster herstellen, es sei denn, VPC Peering ist zwischen den beiden Amazons aktiviert. VPCs
Führen Sie den folgenden Befehl aus, um die Amazon VPC Ihrer Amazon DocumentDB-Instance zu verifizieren.
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].DBSubnetGroup.VpcId'
```
Führen Sie den folgenden Befehl aus, um die Amazon VPC Ihrer Amazon EC2-Instance zu verifizieren.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].VpcId'
```
### Die Sicherheitsgruppe blockiert eingehende Verbindungen
**Sie versuchen, eine Verbindung zu einem Amazon DocumentDB-Cluster herzustellen, und die Sicherheitsgruppe des Clusters erlaubt keine eingehenden Verbindungen auf dem Port des Clusters (Standardport: 27017).**
Angenommen, Ihr Amazon DocumentDB-Cluster und Ihre Amazon EC2 EC2-Instance befinden sich beide in derselben Region und Amazon VPC und verwenden dieselbe Amazon VPC-Sicherheitsgruppe. Wenn Sie keine Verbindung zu Ihrem Amazon DocumentDB-Cluster herstellen können, liegt das wahrscheinlich daran, dass Ihre Sicherheitsgruppe (d. h. die Firewall) für Ihren Cluster keine eingehenden Verbindungen auf dem Port zulässt, den Sie für Ihren Amazon DocumentDB-Cluster ausgewählt haben (Standardport ist 27017).
Führen Sie den folgenden Befehl aus, um den Port für Ihren Amazon DocumentDB-Cluster zu überprüfen.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[DBClusterIdentifier,Port]'
```
Führen Sie den folgenden Befehl aus, um Ihre Amazon DocumentDB-Sicherheitsgruppe für Ihren Cluster abzurufen.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[VpcSecurityGroups[*],VpcSecurityGroupId]'
```
Informationen zur Überprüfung der Regeln für eingehende Nachrichten für Ihre Sicherheitsgruppe finden Sie in den folgenden Themen in der Amazon EC2 EC2-Dokumentation:
+ [Autorisieren von eingehendem Datenverkehr für Ihre Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html)
+ [Autorisieren von eingehendem Datenverkehr für Ihre Windows-Instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html)
### Problem mit den Leseeinstellungen des Java-Mongo-Treibers
**Die Leseeinstellungen der Clients werden nicht berücksichtigt und einige Clients können nach einem Failover nicht in Amazon DocumentDB schreiben, es sei denn, sie starten neu.**
Dieses Problem, das erstmals in Java Mongo Driver 3.7.x entdeckt wurde, tritt auf, wenn ein Client mithilfe `MongoClientSettings` und insbesondere beim Verketten der Methode eine Verbindung zu Amazon DocumentDB herstellt. `applyToClusterSettings` Die MongoClient Cluster-Einstellungen können mit verschiedenen Methoden definiert werden, z. B. mit, und. `hosts()` `requiredReplicaSetName()` `mode()`
Wenn der Client in der `hosts()` Methode nur einen Host angibt, wird der Modus auf `ClusterConnectionMode.SINGLE` statt auf gesetzt. `ClusterConnectionMode.MULTIPLE` Dadurch ignoriert der Client die Lesepräferenz und stellt nur eine Verbindung zu dem Server her, der in `hosts()` konfiguriert ist. Selbst wenn die Client-Einstellungen wie unten initialisiert würden, würden alle Lesevorgänge immer noch an den primären statt an den sekundären weitergeleitet.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx",
"admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder -> builder
.enabled(false))
.applyToClusterSettings(builder -> builder.hosts(
Arrays.asList(serverAddress0
))
.requiredReplicaSetName("rs0"))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
**Failover-Fall**
Bei Verwendung der oben genannten Client-Verbindungseinstellungen würde der Client bei einem Failover und einer verzögerten Aktualisierung des DNS-Eintrags für den Cluster-Writer-Endpunkt trotzdem versuchen, Schreibvorgänge auf den alten Writer (jetzt Reader nach dem Failover) auszuführen. Dies führt zu einem serverseitigen Fehler (nicht primär), der vom Java-Treiber nicht angemessen behandelt wird (dieser Fehler wird noch untersucht). Somit kann der Client in einem schlechten Zustand belassen werden, bis beispielsweise der Anwendungsserver neu gestartet wird.
Dafür gibt es zwei Problemumgehungen:
+ Bei Clients, die über eine Verbindungszeichenfolge eine Verbindung zu Amazon DocumentDB herstellen, tritt dieses Problem nicht auf, da `ClusterConnectionMode` es `MULTIPLE` bei der Einstellung der Leseeinstellungen auf gesetzt wird.
```
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred");
MongoClient mongoClient = MongoClients.create(mongoClientURI.getURI());
```
Oder Sie verwenden `MongoClientSettings` Builder mit der `applyConnectionString` Methode.
```
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.applyConnectionString(new ConnectionString("usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred"))
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
+ Explizit gesetzt `ClusterConnectionMode` auf`MULTIPLE`. Dies ist nur erforderlich, wenn `applyToClusterSettings` und verwendet wird`hosts().size() == 1`.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx","admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.applyToClusterSettings(builder → builder
.hosts(Arrays.asList(serverAddress0))
.requiredReplicaSetName("rs0"))
.mode(ClusterConnectionMode.MULTIPLE))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
## Testen einer Verbindung zu einer Amazon DocumentDB DocumentDB-Instance
Sie können Ihre Verbindung zu einem Cluster mit gängigen Linux- oder Windows-Tools testen.
Testen Sie die Verbindung über einen Linux- oder Unix-Terminal, indem Sie folgendes eingeben (ersetzen Sie `cluster-endpoint` durch den Endpunkt und ersetzen Sie `port` durch den Port Ihrer Instance).
```
nc -zv cluster-endpoint port
```
Der folgende Code ist ein Beispiel für eine Beispieloperation und den Rückgabewert:
```
nc -zv docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017
Connection to docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017 port [tcp/*] succeeded!
```
## Verbindung zu einem ungültigen Endpunkt herstellen
Wenn Sie eine Verbindung zu einem Amazon DocumentDB-Cluster herstellen und einen Cluster-Endpunkt verwenden, der nicht gültig ist, wird ein Fehler ähnlich dem folgenden angezeigt.
```
mongo --ssl \
--host sample-cluster.node.us-east-1.docdb.amazonaws.com:27017 \
--sslCAFile global-bundle.pem \
--username \
--password
```
Das Ergebnis sieht folgendermaßen aus:
```
MongoDB shell version v3.6
connecting to: mongodb://sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/
2018-11-14T17:21:18.516-0800 I NETWORK [thread1] getaddrinfo("sample-cluster.node.us-east-1.docdb.amazonaws.com") failed:
nodename nor servname provided, or not known 2018-11-14T17:21:18.537-0800 E QUERY [thread1] Error: couldn't initialize
connection to host sample-cluster.node.us-east-1.docdb.amazonaws.com, address is invalid :
connect@src/mongo/shell/mongo.js:237:13@(connect):1:6
exception: connect failed
```
Um den gültigen Endpunkt für einen Cluster abzurufen, führen Sie den folgenden Befehl aus:
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[Endpoint,Port]'
```
Um den gültigen Endpunkt für eine Instance abzurufen, führen Sie den folgenden Befehl aus:
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].[Endpoint.Address,Endpoint.Port]'
```
Weitere Informationen finden Sie unter [Grundlegendes zu Amazon DocumentDB DocumentDB-Endpunkten](endpoints.md).
## Die Treiberkonfiguration wirkt sich auf die Anzahl der Verbindungen aus
Wenn Sie den Client-Treiber verwenden, um eine Verbindung zu einem Amazon DocumentDB-Cluster herzustellen, müssen Sie den `maxPoolSize` Konfigurationsparameter berücksichtigen. Die `maxPoolSize` Einstellung bestimmt die maximale Anzahl von Verbindungen, die der Client-Treiber in seinem Verbindungspool unterhält.
# Fehlerbehebung bei Indizes
Die folgenden Themen erläutern, was zu tun ist, wenn Ihr Index oder Ihr Indexaufbau im Hintergrund fehlschlägt.
**Topics**
+ [Die Indexerstellung schlägt fehl](#troubleshooting.index-build-fails)
+ [Latenzprobleme und Fehler bei der Indexerstellung im Hintergrund](#troubleshooting.background-index-build-fails)
+ [Aufblähung des Datenbankindexes](#troubleshooting-database-bloat)
## Die Indexerstellung schlägt fehl
Amazon DocumentDB verwendet lokalen Speicher auf einer Instance als Teil des Indexerstellungsprozesses. Sie können diese Festplattennutzung mithilfe der **FreeLocalStorage** CloudWatch Metrik () `CloudWatch -> Metrics -> DocDB -> Instance Metrics` überwachen. Wenn ein Indexaufbau den gesamten lokalen Festplattenspeicherplatz verbraucht und fehlschlägt, erhalten Sie eine Fehlermeldung. Wenn Sie Daten zu Amazon DocumentDB migrieren, empfehlen wir Ihnen, zuerst Indizes zu erstellen und dann die Daten einzufügen. Weitere Informationen zu Migrationsstrategien und zum Erstellen von Indizes finden Sie [Migration zu Amazon DocumentDB](docdb-migration.md) in der Amazon DocumentDB-Dokumentation und im Blog: [Migrieren Sie mithilfe der Offline-Methode von MongoDB zu Amazon DocumentDB](https://aws.amazon.com/blogs/database/migrate-from-mongodb-to-amazon-documentdb-using-the-offline-method/).
Wenn beim Erstellen von Indizes auf einem vorhandenen Cluster die Indexerstellung länger dauert als erwartet oder fehlschlägt, empfehlen wir, dass Sie die Instance hochskalieren, um den Index zu erstellen, und dann, nachdem der Index erstellt wurde, wieder herunterskalieren. Amazon DocumentDB ermöglicht Ihnen die schnelle Skalierung von Instance-Größen innerhalb von Minuten mit dem AWS-Managementkonsole oder dem AWS CLI. Weitere Informationen finden Sie unter [Instanzklassen verwalten](db-instance-classes.md). Bei der sekundengenauen Instance-Preisgestaltung zahlen Sie auf die Sekunde genau nur für die Ressourcen, die Sie verwenden.
## Latenzprobleme und Fehler bei der Indexerstellung im Hintergrund
Index-Builds im Hintergrund in Amazon DocumentDB werden erst gestartet, wenn alle Abfragen auf der primären Instance, die vor der Initiierung der Indexerstellung gestartet wurden, vollständig ausgeführt wurden. Wenn es eine lang andauernde Abfrage gibt, werden die Index-Builds im Hintergrund blockiert, bis die Abfrage abgeschlossen ist. Daher kann es länger dauern als erwartet, bis sie abgeschlossen ist. Dies gilt auch dann, wenn Sammlungen leer sind.
Index-Builds im Vordergrund zeigen nicht dasselbe Blockierungsverhalten. Stattdessen wird bei Index-Builds im Vordergrund die Sammlung exklusiv gesperrt, bis die Indexerstellung abgeschlossen ist. Um Indizes für eine leere Sammlung zu erstellen und Blockierungen bei Abfragen mit langer Laufzeit zu vermeiden, empfehlen wir daher, Index-Builds im Vordergrund zu verwenden.
**Anmerkung**
Amazon DocumentDB lässt zu, dass zu einem bestimmten Zeitpunkt nur ein Hintergrundindex für eine Sammlung erstellt wird. Wenn DDL (Data Definition Language) Operationen wie `createIndex()` oder `dropIndex()` während eines Indexaufbaus im HIntergrund in derselben Sammlung auftreten, schlägt der Aufbau des Hintergrundindex fehl.
## Aufblähung des Datenbankindexes
Amazon DocumentDB verwendet Multi-Version Concurrency Control (MVCC) zur Verwaltung gleichzeitiger Transaktionen. Wenn Dokumente gelöscht oder aktualisiert werden, verbleiben ihre vorherigen Versionen als „tote“ Versionen in Sammlungen und Indizes. Durch den Garbage-Collection-Prozess wird automatisch Speicherplatz aus diesen toten Versionen für future Operationen zurückgewonnen.
Ein aufgeblähter Index tritt auf, wenn die Indizes einer Sammlung aufgrund der Anhäufung toter oder veralteter Indexeinträge oder der Fragmentierung innerhalb der Seiten größer werden. Der angegebene Prozentsatz entspricht der Menge an Indexspeicher, die von future Indexeinträgen verwendet werden kann. Diese Aufblähung beansprucht Speicherplatz sowohl im Puffer-Cache als auch im Speicher. Wenn Sie den Bloat entfernen möchten, müssen Sie die Indizes neu erstellen.
**Example Beispiel**
Führen Sie den folgenden Befehl aus, um den ungenutzten Speicherplatz für Ihren Index zu ermitteln:
```
db.coll.aggregate({$indexStats:{}});
```
Das Ergebnis sieht in etwa so aus:
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "devbox-test.localhost.a2z.com:27317",
"size" : NumberLong(827392),
"accesses" : {
"ops" : NumberLong(40000),
"docsRead" : NumberLong(46049),
"since" : ISODate("2025-04-03T21:44:51.251Z")
},
"cacheStats" : {
"blksRead" : NumberLong(264),
"blksHit" : NumberLong(140190),
"hitRatio" : 99.8121
},
"unusedStorageSize" : {
"unusedSizeBytes" : 409600,
"unusedSizePercent" : 49.51
}
}
```
Mit dem `reIndex` Befehl können Sie Indizes ohne Ausfallzeiten neu erstellen. Dazu ist ein Scan der gesamten Sammlung erforderlich. Siehe [Indexverwaltung mit `reIndex`](managing-indexes.md#reIndex).
# Problembehebung bei Leistung und Ressourcennutzung
Dieser Abschnitt enthält Fragen und Lösungen für häufig auftretende Diagnoseprobleme in Amazon DocumentDB 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](endpoints.md).
**Topics**
+ [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?](#user-diag-performed-operations)
+ [Wie analysiere ich die Cache-Leistung?](#user-diag-cache-perf)
+ [Wie finde und beende ich langsame und blockierte Abfragen?](#user_diagnostics-query_terminating)
+ [Wie kann ich mir einen Abfrageplan ansehen und eine Abfrage optimieren?](#user_diagnostics-query_plan)
+ [Wie kann ich mir einen Abfrageplan in elastischen Clustern ansehen?](#user-diagnostics-ec-query-plan)
+ [Wie liste ich alle laufenden Operationen für eine Instance auf?](#user_diagnostics-list_queries)
+ [Woher weiß ich, wann eine Abfrage Fortschritte macht?](#user_diagnostics-query_progressing)
+ [Wie stelle ich fest, warum ein System plötzlich langsam läuft?](#user_diagnostics-speed_change)
+ [Wie ermittle ich die Ursache für eine hohe CPU-Auslastung auf einer oder mehreren Cluster-Instances?](#user_diagnostics-cpu_utilization)
+ [Wie ermittle ich die offenen Cursor auf einer Instance?](#user_diagnostics-open_cursors)
+ [Wie finde ich die aktuelle Version der Amazon DocumentDB DocumentDB-Engine heraus?](#user_diagnostics-engine_version)
+ [Wie analysiere ich die Indexnutzung und identifiziere ungenutzte Indizes?](#user-diag-index-usage)
+ [Wie identifiziere ich fehlende Indizes?](#user_diagnostics-identify_missing_indexes)
+ [Wie stelle ich fest, dass die Datenbanksammlung überlastet ist?](#performance-collection-bloat)
+ [Zusammenfassung nützlicher Abfragen](#user_diagnostics-useful_queries)
## 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 unter seinem `opCounters` Feld Folgendes:
+ **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 mit einem Upsert eingefügt wurden.
+ **numDocsUpd**- Die Anzahl der Dokumente, die in dieser Sammlung aktualisiert wurden. 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 Dokumente`deleteOne`, die mit den `findAndModify` Befehlen`deleteMany`,`remove`, und gelöscht wurden.
+ **LastReset** — Der Zeitpunkt, zu dem diese Zähler zuletzt zurückgesetzt wurden. Die mit diesem Befehl bereitgestellten Statistiken werden zurückgesetzt, wenn starting/stopping der Cluster oder die Instanz skaliert up/down wird.
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, die DML-Überwachung zu aktivieren. Die Anzahl der Einfüge-, Aktualisierungs- und Löschvorgänge für alle Sammlungen in Zeitintervallen von einer Minute kann in einminütigen Zeitintervallen eingesehen werden. [Überwachen von Amazon DocumentDB mit CloudWatch](cloud_watch.md)
## Wie analysiere ich die Cache-Leistung?
Die Analyse der Cache-Leistung kann Aufschluss über die Effizienz des Datenabrufs und die 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 (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 im `cacheStats` Feld in der Ausgabe dieses Befehls liefern Cache-Statistiken für die Sammlung sowie die gesamten Cache-Statistiken für die Indizes, die für die Sammlung erstellt wurden. Diese Statistiken sind unten aufgeführt:
+ **`collBlksHit`**- Die Anzahl der Blöcke, die während der Operationen an dieser Sammlung aus dem Cache gelesen wurden.
+ **`collBlksRead`**- Die Anzahl der Blöcke, die bei Vorgängen an dieser Sammlung von der Festplatte gelesen wurden (Cache-Fehlschläge).
+ **`collHitRatio`**— Die Cache-Trefferquote für diese Sammlung (`100 * [collBlksHit / (collBlksHit + collBlksRead)]`).
+ **`idxBlksHit`**- Die Anzahl der Blöcke, die für jeden Index, der für diese Sammlung erstellt wurde, aus dem Cache gelesen wurden.
+ **`idxBlksRead`**- Die Anzahl der von der Festplatte gelesenen Blöcke (Cache-Fehlschläge) für jeden Index, der für diese Sammlung erstellt wurde.
+ **`idxHitRatio`**— Die Cache-Trefferquote für die Indizes, die für diese Sammlung erstellt wurden (`100 * [idxBlksHit / (idxBlksHit + idxBlksRead)]`).
+ **`lastReset`**- Der Zeitpunkt, zu dem diese Statistiken zuletzt zurückgesetzt wurden. Die von bereitgestellten Statistiken `db.collection.stats()` werden zurückgesetzt, wenn starting/stopping der Cluster oder up/down die Instanz skaliert 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 auf vier Dezimalstellen gerundete Cache-Trefferquote, berechnet von`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
}
```
1. Beenden Sie die Abfrage mit der Operation `killOp`.
```
db.adminCommand({killOp: 1, op: 24646});
```
## Wie kann ich mir einen Abfrageplan ansehen 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, selbstheilendes Speichersystem verwendet. Daher `explain()` können sich die Abfragepläne und die Ausgabe von zwischen Amazon DocumentDB und MongoDB unterscheiden. 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: {}})
```
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 DocumentDB-Abfrageprozessor entscheiden, keinen Index zu verwenden, wenn die Leistungssteigerung vernachlässigbar ist.
## Wie kann ich mir einen Abfrageplan in elastischen Clustern ansehen?
Verwenden Sie den `explain` Befehl, um einen Abfrageplan in elastischen Clustern zu untersuchen. Im Folgenden finden Sie einen `explain` Beispielvorgang 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 sich die Abfragepläne und die Ausgabe von zwischen Amazon DocumentDB und MongoDB unterscheiden. Sie können den Abfrageplan mithilfe des `$hint` Operators steuern, um die Auswahl eines bevorzugten Indexes zu erzwingen.
Die Ausgabe dieses Vorgangs 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 Eingabestufen haben können. In diesem Beispiel wird ein „COLLSCAN“ (ein Sammlungsscan) auf allen Partitionen ausgeführt, bevor die Ergebnisse in der Phase“ PARTITION\$1MERGE „innerhalb jedes Shards zusammengeführt werden. Die Ergebnisse aller Shards werden dann in der Phase“ SHARD\$1MERGE „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 zu Diagnose- und Fehlerbehebungszwecken häufig alle aktuellen Operationen auflisten, die auf einer Instanz ausgeführt werden. (Weitere Informationen zum Verwalten von Benutzern finden Sie unter [Amazon DocumentDB DocumentDB-Benutzer verwalten](security.managing-users.md).)
Mit der `mongo` Shell können Sie die folgende Abfrage verwenden, um alle laufenden Operationen auf einer Amazon DocumentDB 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 Cursorbereinigung oder Aufgaben zur Bereinigung veralteter Benutzer.
+ **TTLMonitor**— Der Time to Live (TTL) -Monitor-Thread. Der Ausführungsstatus wird im Feld `"active"` dargestellt.
+ **GARBAGE\$1COLLECTION**— 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 Stapel von Ergebnissen zu erhalten. In diesem Zustand verbraucht der Cursor Speicher, verbraucht aber 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 Hauptbenutzer des Systems können Sie die 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 Abfrage 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. 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 läuft?
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?](#user_diagnostics-query_terminating).
## 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.
+ Informationen dazu, wie Sie ermitteln, warum eine Instance plötzlich langsam ausgeführt wird, finden Sie unter [Wie stelle ich fest, warum ein System plötzlich langsam läuft?](#user_diagnostics-speed_change).
+ Informationen zum Identifizieren und Beenden langsamer Abfragen auf einer bestimmten Instance finden Sie unter [Wie finde und beende ich langsame und blockierte Abfragen?](#user_diagnostics-query_terminating).
+ Informationen dazu, wie Sie ermitteln, ob eine Abfrage fortschreitet, finden Sie unter [Woher weiß ich, wann eine Abfrage Fortschritte macht?](#user_diagnostics-query_progressing).
+ Informationen dazu, warum die Ausführung einer Abfrage lange dauert, finden Sie unter [Wie kann ich mir einen Abfrageplan ansehen und eine Abfrage optimieren?](#user_diagnostics-query_plan).
+ Informationen dazu, wie Sie langsame Abfragen über die Zeit nachverfolgen, finden Sie unter [Profilierung von Amazon DocumentDB DocumentDB-Vorgängen](profiling.md).
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 [Als Replikatsatz eine Verbindung zu Amazon DocumentDB herstellen](connect-to-replica-set.md).
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 erhalten Sie unter [Instances](what-is.md#what-is-db-instances) und [Spezifikationen der Instanzklasse](db-instance-classes.md#db-instance-class-specs).
+ 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 DocumentDB-Instance zu einem Cluster](db-instance-add.md).
## Wie ermittle ich die offenen Cursor auf einer Instance?
Wenn Sie mit einer Amazon DocumentDB DocumentDB-Instance verbunden sind, können Sie den Befehl verwenden, `db.runCommand("listCursors")` um die geöffneten Cursor auf dieser Instance aufzulisten. Es gibt ein Limit von bis zu 4.560 aktiven Cursorn, die zu einem bestimmten Zeitpunkt auf einer bestimmten Amazon DocumentDB DocumentDB-Instance geöffnet sind, je nach Instance-Typ. 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 Grenzwerte finden Sie unter[Amazon DocumentDB Kontingente und Beschränkungen](limits.md).
```
db.runCommand("listCursors")
```
## Wie finde ich die aktuelle Version der Amazon DocumentDB DocumentDB-Engine heraus?
Führen Sie den folgenden Befehl aus, um Ihre aktuelle Amazon DocumentDB 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, die Engine-Version für Amazon DocumentDB 4.0 ist 2.x.x, die Engine-Version für Amazon DocumentDB 5.0 ist 3.x.x und die Engine-Version für Amazon DocumentDB 8.0 ist 4.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 Vorgängen 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 mit Indizes (Indexscans) durchgeführten Scans mit der Anzahl der ohne Index durchgeführten Scans (Sammlungsscans) zu vergleichen:
```
db.collection.stats()
```
Die Ausgabe für diesen Befehl umfasst die folgenden Werte:
+ **`idxScans`**- Die Anzahl der Scans, die für diese Sammlung mithilfe eines Indexes durchgeführt wurden.
+ **`collScans`**- Die Anzahl der Scans, die für diese Sammlung ohne Verwendung eines Indexes durchgeführt wurden. Bei diesen Scans hätten die Dokumente in der Sammlung nacheinander durchsucht werden müssen.
+ **`lastReset`**- Der Zeitpunkt, zu dem diese Zähler zuletzt zurückgesetzt wurden. Die mit diesem Befehl bereitgestellten Statistiken werden beim Clustern oder Skalieren starting/stopping up/down der Instance zurückgesetzt.
Eine Aufschlüsselung, wie häufig die einzelnen Indizes verwendet werden, 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 dadurch unnötige Rechenleistung, Speicherung und Nutzung I/Os zur Verwaltung der Indizes vermieden werden.
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
Die Ausgabe dieses Befehls enthält 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 bei Vorgängen gelesen wurden, die diesen Index verwenden.
+ **`since`**— Die Zeit, seit Amazon DocumentDB mit der Erfassung von Statistiken zur Indexnutzung begonnen hat. Dies ist in der Regel der Wert seit dem letzten Datenbankneustart oder der letzten Wartungsaktion.
+ **`size`**- Die Größe dieses Indexes in Byte.
Das folgende Beispiel ist eine Beispielausgabe aus 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 DocumentDB-Profiler verwenden, um langsame Abfragen zu protokollieren](https://docs.aws.amazon.com//documentdb/latest/developerguide/profiling.html). 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 über eine oder mehrere Phasen verfügen, die mindestens eine `COLLSCAN` Phase ausführen. Das bedeutet, dass in der Abfragephase jedes Dokument in der Sammlung gelesen werden 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 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} )
```
**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 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 überlastet ist?
Eine Aufblähung von Sammlungen 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 entspricht der Menge an Dokumentenspeicher, die von future Dokumenten verwendet werden kann. Diese Aufblähung beansprucht Speicherplatz sowohl im Puffercache als auch im Speicher. Um diese Aufblähung zu beseitigen, müssen Sammlungen während eines Wartungsfensters dump/restore entweder über einen Migrations-Loopback und einen Switchover neu geladen werden.
**Example Beispiel**
Führen Sie den folgenden Befehl aus, um den ungenutzten Speicherplatz für Ihre Sammlung zu ermitteln:
```
db.runCommand({collStats:'coll'})
```
Das Ergebnis sieht in etwa so aus:
```
{
"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 Ressourcennutzung in Amazon DocumentDB nützlich sein.
+ Verwenden Sie den folgenden Befehl, um Statistiken über eine bestimmte Sammlung anzuzeigen, einschließlich Betriebszä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 Indexes, indexspezifischer Cache-Statistiken und Statistiken zur Indexnutzung:
```
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: });
```
+ 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: {}
});
```
# Müllabfuhr in Amazon DocumentDB
Amazon DocumentDB implementiert eine MVCC-Datenbankarchitektur (Multi-Version Concurrency Control), die für jeden Aktualisierungsvorgang neue Versionen von Dokument- und Indexeinträgen erstellt. Diese Architektur ermöglicht die Isolierung von Transaktionen und verhindert so, dass die Änderungen einer Transaktion in einer anderen erscheinen.
**Topics**
+ [Grundlegendes zur Müllabfuhr in Amazon DocumentDB](#understanding-garbage-collection)
+ [Prozess der Müllabfuhr](#garbage-collection-process)
+ [Speicherarchitektur und erweiterter Speicher](#storage-architecture)
+ [Überwachung der Müllabfuhr](#monitoring-garbage-collection)
+ [Beispiel für eine CollStats-Ausgabe](#example-collstats-output)
+ [Häufig gestellte Fragen](#garbage-collection-faq)
## Grundlegendes zur Müllabfuhr in Amazon DocumentDB
Garbage Collection (GC) ist ein automatisierter Hintergrundprozess, der eine optimale Systemleistung und Verfügbarkeit in Amazon DocumentDB gewährleistet. Wie viele moderne Datenbanken erstellt auch die MVCC-Architektur von Amazon DocumentDB mit jeder Aktualisierung neue Dokument- und Indexversionen. Jeder Schreibvorgang verbraucht eine eindeutige MVCC-ID aus einem endlichen Zähler. Diese IDs geben an, zu welcher Transaktion eine Dokumentversion gehört und ob sie festgeschrieben oder zurückgesetzt wurde. Im Laufe der Zeit IDs häufen sich diese alten Versionen und ihr MVCC an, sodass eine Bereinigung erforderlich ist, um Leistungseinbußen vorzubeugen.
### Funktionen der Müllabfuhr
Der Müllsammler erfüllt drei wesentliche Funktionen:
+ **Gewinnt Speicherplatz zurück** — Es entfernt veraltete Dokument- und Indexversionen, die für aktive Abfragen nicht mehr benötigt werden, und gibt so Speicherplatz für future Schreibvorgänge frei.
+ **Beugt einem MVCC-ID-Überlauf** vor — Es verhindert einen MVCC-ID-Überlauf, indem der endliche Zähler von MVCC verwaltet wird. IDs Ohne diese Verwaltung würde der Zähler irgendwann sein Limit erreichen und die Datenbank in einen temporären Nur-Lese-Modus zwingen, bis sie recycelt werden. IDs
+ **Beibehaltung der Abfrageleistung** — Es sorgt für eine optimale Abfrageleistung, indem veraltete Dokumentversionen entfernt werden, die sich andernfalls ansammeln und die Abfrageverarbeitung verlangsamen würden.
## Prozess der Müllabfuhr
Der GC-Prozess wird pro Sammlung ausgeführt und es können mehrere Prozesse gleichzeitig in verschiedenen Sammlungen ausgeführt werden. Der Prozess besteht aus vier aufeinanderfolgenden Phasen:
1. **Identifizierung** — Das System identifiziert Dokument- und Indexversionen, auf die in aktiven Transaktionen oder Abfragen nicht mehr verwiesen wird.
1. **Laden des Speichers** — Alte Dokumente und Indexeinträge werden in den Speicher geladen, sofern sie nicht bereits vorhanden sind.
1. **Löschen** — Veraltete Versionen werden dauerhaft gelöscht, um Speicherplatz zurückzugewinnen.
1. **MVCC-ID-Recycling** — Das System recycelt MVCC IDs aus gelöschten Versionen für neue Operationen.
Wenn die Garbage-Collection die Verarbeitung alter Dokumentversionen abgeschlossen hat, entfernt es das älteste MVCC IDs aus dem System. Diese Bereinigung ist entscheidend, um einen MVCC-ID-Überlauf zu verhindern IDs, indem MVCC recycelt und für neue Schreibvorgänge im gesamten Cluster verfügbar gemacht werden. Ohne diesen Recyclingprozess würde das System irgendwann seinen begrenzten MVCC-ID-Zähler erschöpfen und in einen schreibgeschützten Zustand übergehen.
### Planung der Müllabfuhr
Die Müllabfuhr wird in regelmäßigen Abständen automatisch im Hintergrund ausgeführt. Das Timing und die Frequenz passen sich dynamisch an die Systemlast, die verfügbaren Ressourcen, das Schreibvolumen und den MVCC-ID-Verbrauch an. Bei hoher Schreibaktivität wird der GC-Prozess häufiger ausgeführt, um die erhöhte Anzahl von Dokumentversionen zu bewältigen.
## Speicherarchitektur und erweiterter Speicher
Amazon DocumentDB verwendet eine ausgeklügelte Speicherarchitektur, die den Dokumentenspeicher in zwei unterschiedliche Segmente unterteilt:
### Basisspeichersegment
Das Basisspeichersegment enthält die primären Dokumentdaten und Metadaten. In diesem Segment wird Folgendes gespeichert:
+ Dokumentinhalt, der in die Standardseitengröße (8 KB) passt.
+ Metadaten und Strukturinformationen des Dokuments.
+ Primärindizes und ihre Einträge.
+ Statistiken und Konfiguration auf Sammlungsebene.
### Erweitertes Speichersegment
Das erweiterte Speichersegment verwendet einen speziellen Objektspeicher für große Dokumente, der für die Verarbeitung von Dokumenten konzipiert ist, die die Standardspeicherseitengröße überschreiten. Dieses Segment bietet:
+ **Effizienter Umgang mit großen Dokumenten** — Dokumente, die den Basisspeicherschwellenwert überschreiten, werden automatisch in das erweiterte Speichersegment verschoben.
+ **Optimiertes Speicherlayout** — Das Segment verwendet ein anderes Speicherformat, das für große Objekte optimiert ist, wodurch die Fragmentierung reduziert und die Zugriffsmuster verbessert werden.
+ **Unabhängige Speicherbereinigung** — Das erweiterte Speichersegment verfügt über einen eigenen Speicherbereinigungsprozess, der unabhängig von der Bereinigung des Basisspeichers ausgeführt werden kann.
+ **Transparenter Zugriff** — Anwendungen greifen problemlos auf große Dokumente zu, ohne wissen zu müssen, welches Speichersegment die Daten enthält.
Das erweiterte Speichersegment ist besonders vorteilhaft für:
+ Sammlungen mit Dokumenten, die große eingebettete Arrays enthalten.
+ Dokumente mit umfangreichen verschachtelten Strukturen.
+ Sammlungen, die Binärdaten oder große Textfelder speichern.
+ Anwendungen mit gemischten Dokumentengrößen, bei denen einige Dokumente die durchschnittliche Größe deutlich überschreiten.
## Überwachung der Müllabfuhr
### Metriken auf Clusterebene
**`AvailableMVCCIds`**
+ **Standort** — Amazon CloudWatch
+ **Beschreibung** — Ein Zähler, der die Anzahl der verbleibenden Schreibvorgänge anzeigt, die ab einer Höchstgrenze von 1,8 Milliarden verfügbar sind. Wenn dieser Zähler Null erreicht, wechselt Ihr Cluster in den schreibgeschützten Modus, bis die Daten zurückgewonnen und IDs recycelt werden. Der Zähler nimmt mit jedem Schreibvorgang ab und steigt, wenn alte MVCCs bei der Garbage-Collection recycelt werden. IDs
+ **Empfehlung** — Stellen Sie einen Alarm ein, wenn der Wert unter 1,3 Milliarden fällt. Diese Frühwarnung ermöglicht es Ihnen, empfohlene Maßnahmen zu ergreifen, die später besprochen werden.
**`LongestActiveGCRuntime`**
+ **Standort** — Amazon CloudWatch
+ **Beschreibung** — Dauer des längsten aktiven Müllsammelvorgangs in Sekunden. Wird jede Minute aktualisiert und verfolgt nur aktive Vorgänge, ausgenommen Prozesse, die innerhalb des Zeitfensters von einer Minute abgeschlossen werden.
+ **Empfehlung**: Vergleichen Sie mit `gcRuntimeStats` historischen Daten, um ungewöhnliches Verhalten bei der Speicherbereinigung zu ermitteln, z. B. längere Laufzeiten bei Massenlöschungen.
### Kennzahlen auf Erfassungsebene
**`MVCCIDStats: MVCCIdScale`**
+ **Standort** — Datenbankbefehl CollStats
+ **Beschreibung** — Misst das Alter der MVCC-ID auf einer Skala von 0 bis 1, wobei 1 das maximale Alter angibt, bevor ein Cluster in den schreibgeschützten Zustand übergeht. Verwenden Sie diese Metrik zusammen`AvailableMVCCIds`, um Sammlungen zu identifizieren, die die ältesten MVCCs enthalten IDs , die den Cluster altern lassen.
+ **Empfehlung** — Behalten Sie für jede Sammlung Werte unter 0,3 bei.
**`gcRuntimeStats`**
+ **Standort** — Datenbankbefehl CollStats
+ **Beschreibung** — Stellt eine zweimonatige Historie von Messdaten zur Garbage-Collection bereit, einschließlich der Gesamtzahl der Durchläufe, der durchschnittlichen Dauer und der Höchstdauer. Schließt nur Müllabfuhr ein, die länger als fünf Minuten dauern, um aussagekräftige Statistiken zu gewährleisten.
**Wichtig**
`gcRuntimeStats``documentFragmentStats`, und die Aufteilung der Metriken auf Sammlungsebene in Amazon DocumentDB `storageSegmentBase` 8.0 und `storageSegmentExtended` sind nur für Amazon DocumentDB 8.0 verfügbar.
**`storageSizeStats`**
+ **Standort** — Datenbankbefehl CollStats
+ **Beschreibung** — Bietet eine detaillierte Aufschlüsselung der Speichernutzung in verschiedenen Speichersegmenten:
+ `storageSegmentBase`— Speicher, der vom Basisspeichersegment für Standarddokumente verwendet wird
+ `storageSegmentExtended`— Speicher, der vom erweiterten Speichersegment für große Dokumente verwendet wird
+ **Nutzung** — Hilft bei der Identifizierung von Sammlungen mit sehr großem Dokumentenbestand und hilft dabei, die Speicherverteilungsmuster zu verstehen.
**`unusedStorageSize`**(Sammlungsebene)
+ **Standort** — Datenbankbefehl CollStats
+ **Beschreibung** — Schätzt den ungenutzten Speicherplatz in einer Sammlung auf der Grundlage von Stichprobenstatistiken. Es umfasst Speicherplatz aus gelöschten Dokumenten und leeren Segmenten. Die Metrik bietet sowohl kombinierte Gesamtwerte als auch Aufschlüsselungen pro Segment:
+ Kombiniert `unusedBytes` und für `unusedPercent` alle Speichersegmente
+ `storageSegmentBase`— Ungenutzter Speicherplatz speziell im Basisspeichersegment
+ `storageSegmentExtended`— Ungenutzter Speicherplatz speziell im erweiterten Speichersegment
**`documentFragmentStats`**
+ **Standort** — Datenbankbefehl CollStats
+ **Beschreibung** — Stellt detaillierte Informationen über Dokumentfragmente und tote Daten in Sammlungen bereit. Dokumentfragmente stellen die internen Speichereinheiten dar, die von der Datenbank-Engine verwendet werden, und tote Fragmente weisen auf Daten hin, auf die nicht mehr zugegriffen werden kann, die aber noch nicht zurückgewonnen wurden. Diese Metrik beinhaltet:
+ `totalDocFragmentsCount`— Gesamtzahl der Dokumentfragmente in der Sammlung
+ `deadDocFragmentsCount`— Anzahl der Fragmente, die tote (unzugängliche) Daten enthalten
+ `deadDocFragmentsPercent`— Prozentsatz der Fragmente, die tote Daten enthalten
+ `deadDocFragmentBytes`— Geschätzter Byteverbrauch durch tote Dokumentfragmente
+ Aufschlüsselung nach Segmenten für und `storageSegmentBase` `storageSegmentExtended`
+ **Nutzung** — Überwachen Sie diese Kennzahl, um sich ein Bild von der Effektivität der Müllabfuhr zu machen und um Sammlungen zu identifizieren, die von Wartungsarbeiten profitieren könnten. Ein hoher Prozentsatz an toten Fragmenten deutet darauf hin, dass die Müllabfuhr möglicherweise ins Hintertreffen gerät oder dass die Sammlung von Optimierungen profitieren würde.
### Kennzahlen auf Indexebene
**`unusedStorageSize`**(Indexebene)
+ **Standort** — Befehl IndexStats für die Datenbank
+ **Beschreibung** — Schätzt den ungenutzten Speicherplatz in einem Index auf der Grundlage von Stichprobenstatistiken. Es beinhaltet Speicherplatz aus veralteten Indexeinträgen und leeren Segmenten.
+ **Empfehlung** — Verwenden Sie den `reIndex` Befehl, um Indizes ohne Ausfallzeiten neu zu erstellen und ungenutzten Speicherplatz zurückzugewinnen. Weitere Informationen finden Sie unter Indizes verwalten.
## Beispiel für eine CollStats-Ausgabe
Das folgende Beispiel zeigt eine typische `collStats` Ausgabe mit Metriken zur Garbage-Collection und Speicherung:
```
{
"ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
"MVCCIdStats" : {
"MVCCIdScale" : 0.03
},
"gcRuntimeStats" : {
"numRuns" : 1,
"historicalAvgRuntime" : 3295,
"historicalMaxRuntime" : 3295,
"lastRuntime" : 3295,
"lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
},
"documentFragmentStats" : {
"totalDocFragmentsCount" : 45000000,
"deadDocFragmentsCount" : 2250000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 98304000,
"storageSegmentBase" : {
"totalDocFragmentsCount" : 30000000,
"deadDocFragmentsCount" : 1500000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 65536000
},
"storageSegmentExtended" : {
"totalDocFragmentsCount" : 15000000,
"deadDocFragmentsCount" : 750000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 32768000
}
},
"collScans" : 14,
"count" : 30000000,
"size" : 1320000000,
"avgObjSize" : 44,
"storageSize" : 6461497344,
"storageSizeStats" : {
"storageSegmentBase" : 4307664896,
"storageSegmentExtended" : 2153832448
},
"capped" : false,
"nindexes" : 2,
"totalIndexSize" : 9649553408,
"indexSizes" : {
"_id_" : 1910661120,
"c_1" : 7738892288
},
"unusedStorageSize" : {
"unusedBytes" : 4201881600,
"unusedPercent" : 65.05,
"storageSegmentBase" : {
"unusedBytes" : 2801254400,
"unusedPercent" : 65.05
},
"storageSegmentExtended" : {
"unusedBytes" : 1400627200,
"unusedPercent" : 65.05
}
},
"cacheStats" : {
"collBlksHit" : 171659016,
"collBlksRead" : 754061,
"collHitRatio" : 99.5627,
"idxBlksHit" : 692563636,
"idxBlksRead" : 1177921,
"idxHitRatio" : 99.8303
},
"idxScans" : 41823984,
"opCounter" : {
"numDocsIns" : 0,
"numDocsUpd" : 20911992,
"numDocsDel" : 0
},
"lastReset" : "2025-06-24 05:57:08.219711+00",
"ok" : 1,
"operationTime" : Timestamp(1750968826, 1)
}
```
## Häufig gestellte Fragen
### Wie erkenne ich, ob die Müllabfuhr nicht effizient funktioniert?
Achten Sie auf diese Warnzeichen, die auf eine ineffiziente Müllabfuhr hinweisen:
+ **Übermäßiges Aufblähen von Datensammlungen** — Stetig steigende `unusedStorageSize` Messwerte bei umfangreichen Schreibvorgängen oder Massenlöschungen, insbesondere bei großen Indizes.
+ **Hoher Prozentsatz an toten Fragmenten** — `documentFragmentStats` zeigt konstant hohe `deadDocFragmentsPercent` Werte (über 10-15%).
+ **Verminderte Abfragelatenz** — Erhöhte Abfragelatenz aufgrund der Anhäufung toter Dokumente.
+ **Verlängerte GC-Dauer** — Die Müllabfuhr dauert länger als der historische Durchschnitt in`gcRuntimeStats`.
+ **Erhöhte GC-Verarbeitung** — Hoch `LongestActiveGCRuntime` bedeutet, dass der Garbage Collector nicht mit den Systemanforderungen Schritt halten kann.
### Beeinträchtigt die Garbage-Collection die Leistung meiner Datenbank?
Unter normalen Bedingungen hat die Garbage-Collection nur minimale Auswirkungen auf die Leistung. Wenn die Müllabfuhr jedoch ins Hintertreffen gerät, kann es zu folgenden Problemen kommen:
+ Erhöhte Speicherkosten aufgrund angesammelter toter Dokumente.
+ Langsamere Abfrageleistung aufgrund veralteter Indexeinträge.
+ Temporärer Nur-Lese-Modus, wenn MVCC IDs aufgebraucht sind.
+ Höherer Ressourcenverbrauch bei intensiven Erfassungsläufen, insbesondere bei kleineren Instanzen.
+ Geringere Effizienz bei Operationen mit erweiterten Speichersegmenten für große Dokumente.
### Kann ich die Müllabfuhr manuell auslösen?
Nein, die Garbage-Collection in Amazon DocumentDB kann nicht manuell ausgelöst werden. Das System verwaltet die Müllabfuhr im Rahmen seiner internen Wartungsarbeiten automatisch.
### Welche Alarme sollte ich als bewährte Methode für den Betrieb einrichten?
Wir empfehlen, die Überwachung sowohl auf Cluster- als auch auf Sammlungsebene einzurichten, um eine optimale Leistung Ihres Amazon DocumentDB-Systems sicherzustellen.
Für die Überwachung auf Clusterebene erstellen Sie zunächst einen CloudWatch Amazon-Alarm für die `AvailableMVCCIds` Metrik mit einem Schwellenwert von 1,3 Milliarden. Auf diese Weise haben Sie ausreichend Zeit, um Maßnahmen zu ergreifen, bevor die Metrik Null erreicht. Ab diesem Zeitpunkt würde Ihr Cluster in den schreibgeschützten Modus wechseln. Denken Sie daran, dass diese Kennzahl je nach Ihren spezifischen Nutzungsmustern schwanken kann. Manche Kunden gehen davon aus, dass sie unter 1,3 Milliarden fällt und sich dann wieder auf über 1,5 Milliarden erholt, sobald die Garbage-Collection ihre Arbeit abgeschlossen hat.
Es ist auch wichtig, die `LongestActiveGCRuntime` Metrik über Amazon zu überwachen CloudWatch. Diese Metrik hilft Ihnen`gcRuntimeStats`, zu verstehen, wie effizient die Speicherbereinigung in Ihrem gesamten System funktioniert.
Konzentrieren Sie sich bei der Überwachung auf Sammlungsebene auf die folgenden wichtigen Kennzahlen:
+ `MVCCIdScale`— Achten Sie auf steigende Werte, die darauf hindeuten, dass MVCC IDs altern und möglicherweise Aufmerksamkeit erfordern.
+ `gcRuntimeStats`— Identifizieren Sie Prozesse zur Müllabfuhr, die ungewöhnlich lange dauern oder sich über mehrere Tage erstrecken.
+ `documentFragmentStats`— `deadDocFragmentsPercent` Werte überwachen — konstant hohe Prozentsätze (über 10-15%) können darauf hindeuten, dass die Müllabfuhr hinterherhinkt.
+ `storageSizeStats`und `unusedStorageSize` — Verfolgen Sie die Muster der Speichernutzung und identifizieren Sie Sammlungen mit erheblichem ungenutztem Speicherplatz in beiden Speichersegmenten.
Sammlungen mit häufigen Schreibvorgängen erfordern besondere Aufmerksamkeit, da sie mehr Arbeit für den Garbage-Collector bedeuten. Wir empfehlen, diese Metriken bei Sammlungen mit starker Schreibaktivität häufiger zu überprüfen, um sicherzustellen, dass die Garbage-Collection mit Ihrer Arbeitslast Schritt hält.
Beachten Sie, dass diese Überwachungsempfehlungen als Ausgangspunkt dienen. Wenn Sie mit dem Verhalten Ihres Systems besser vertraut sind, sollten Sie diese Schwellenwerte möglicherweise anpassen, um sie besser an Ihre spezifischen Nutzungsmuster und Anforderungen anzupassen.
### Was sollte ich tun, wenn mein Wert unter 1,3 Milliarden `AvailableMVCCIds` fällt?
Wenn Ihre `AvailableMVCCIds` Metrik unter 1,3 Milliarden fällt, empfehlen wir, sofort Maßnahmen zu ergreifen, um zu verhindern, dass Ihr Cluster in den schreibgeschützten Modus wechselt. Wir empfehlen, zunächst Ihre Instance-Größe zu vergrößern, um dem Garbage Collector mehr Rechenressourcen zur Verfügung zu stellen. Dies ist unsere wichtigste Empfehlung, da es Ihrer Anwendung ermöglicht, den normalen Betrieb fortzusetzen und gleichzeitig dem Garbage Collector die zusätzliche Leistung zu geben, die er zum Aufholen benötigt.
Wenn eine Skalierung allein die Situation nicht verbessert, empfehlen wir, eine Reduzierung Ihrer Schreibvorgänge in Betracht zu ziehen. Identifizieren Sie anhand der `MVCCIdScale` Metrik, welche spezifischen Sammlungen ältere MVCCs enthalten IDs , die bearbeitet werden müssen. Überwachen Sie außerdem Sammlungen mit einem hohen Prozentsatz `documentFragmentStats` an toten Fragmenten, die möglicherweise zur Ineffizienz der Müllsammlung beitragen.
Sobald Sie diese Sammlungen identifiziert haben, müssen Sie möglicherweise vorübergehend die Schreibvorgänge auf sie reduzieren, damit die Garbage-Collection aufholen kann. Während der Erholungsphase empfehlen wir, die `AvailableMVCCIds` Metrik genau zu beobachten, um sicherzustellen, dass Ihre Maßnahmen die gewünschte Wirkung haben. Ihr Cluster gilt als fehlerfrei, sobald der `AvailableMVCCIds` Wert wieder 1,5 Milliarden oder höher erreicht.
Denken Sie daran, dass es sich bei diesen Schritten um vorbeugende Maßnahmen handelt, mit denen Ihr System wiederhergestellt werden kann, bevor es einen kritischen Zustand erreicht. Je früher Sie Maßnahmen ergreifen, nachdem der Wert unter 1,3 Milliarden gesunken ist, desto wahrscheinlicher ist es, dass Sie jegliche Auswirkungen auf Ihre Schreibvorgänge vermeiden.