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 bietet Leseisolierung, indem Leseabfragen versionierte Dokumente verwenden können, ohne dass Sperren erforderlich sind.

Grundlegendes zur Garbage Collection in Amazon DocumentDB

Garbage Collection (GC) ist ein automatisierter Hintergrundprozess, der eine optimale Systemleistung und Verfügbarkeit in Amazon DocumentDB gewährleistet. Im Gegensatz zu herkömmlichen Datenbanken, die Daten an Ort und Stelle überschreiben, erstellt die MVCC-Architektur von Amazon DocumentDB bei jedem Aktualisierungsvorgang neue Versionen von Dokumenten und Indexeinträgen. Jeder Schreibvorgang, der zu einer neuen Dokumentversion führt, verbraucht eine eindeutige MVCC-ID aus einem begrenzten Zähler, sodass eine effiziente Bereinigung unerlässlich ist. Im Laufe der Zeit häufen sich diese alten Versionen an und müssen bereinigt werden, um Leistungseinbußen zu vermeiden.

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.

2. Laden des Speichers — Alte Dokumente und Indexeinträge werden in den Speicher geladen, sofern sie nicht bereits vorhanden sind.

3. Löschen — Veraltete Versionen werden dauerhaft gelöscht, um Speicherplatz zurückzugewinnen.

4. 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.

Überwachung der Müllabfuhr

Metriken auf Clusterebene

AvailableMVCCIds

• Standort — Amazon CloudWatch

• Beschreibung — Ein Zähler, der die Anzahl der verbleibenden verfügbaren Schreibvorgänge anzeigt, bevor der Wert Null erreicht wird. 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.

LongestRunningGCProcess

• 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 —

Kennzahlen auf Erfassungsebene

MVCCIDStats: MvccIdAgeScale

• 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 zusammenAvailableMVCCIds, 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.

UnusedStorageSize(Sammelebene)

• 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.

Metriken 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 collStats eine Ausgabe

{
    "ns": "xid_consumption_test_db.xid_test_collection",
    "MVCCIdStats": {
        "MVCCIdScale": 0.03
    },
    "gcRuntimeStats": {
        "numRuns": 1,
        "historicalAvgRuntime": 3295,
        "historicalMaxRuntime": 3295,
        "lastRuntime": 3295,
        "lastRuntimeStart": ISODate("2025-06-24T08:47:14Z")
    },
    "collScans": 14,
    "count": 30000000,
    "size": 1320000000,
    "avgObjSize": 44,
    "storageSize": 6461497344,
    "capped": false,
    "nindexes": 2,
    "totalIndexSize": 9649553408,
    "indexSizes": {
        "_id_": 1910661120,
        "c_1": 7738892288
    },
    "unusedStorageSize": {
        "unusedBytes": 4201881600,
        "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

Themen

• Wie erkenne ich, ob die Müllabfuhr nicht effizient funktioniert?

• Beeinträchtigt die Garbage-Collection die Leistung meiner Datenbank?

• Kann ich die Garbage-Collection manuell auslösen?

• Welche Alarme sollte ich als bewährte Methode für den Betrieb einrichten?

• Was sollte ich tun, wenn mein Wert unter 1,3 Milliarden AvailableMVCCId fällt?

Wie erkenne ich, ob die Müllabfuhr nicht effizient funktioniert?

Achten Sie auf diese Warnzeichen, die auf eine ineffiziente Müllabfuhr hinweisen:

• Übermäßige Menge an Datensammlungen — Stetig steigende UnusedStorageSize Messwerte bei umfangreichen Schreibvorgängen oder Massenlöschungen, insbesondere bei großen Indizes

• Verminderte Abfragelatenz — Erhöhte Abfragelatenz aufgrund der Anhäufung toter Dokumente

• Verlängerte GC-Dauer — Die Müllabfuhr dauert länger als die historischen Durchschnittswerte in GCRuntimeStats

• Erhöhte GC-Verarbeitung — Hoch LongestRunningGCProcess 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 Sammlungsläufen, insbesondere bei kleineren Instanzen.

Kann ich die Garbage-Collection manuell auslösen?

Nein, die Speicherbereinigung 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 Alarm für die AvailableMVCCId 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. Beachten Sie, dass diese Metrik je nach Ihren spezifischen Nutzungsmustern schwanken kann. Manche Kunden gehen davon aus, dass sie unter 1,3 Milliarden fallen und sich dann wieder auf über 1,5 Milliarden erholen, wenn die Müllabfuhr ihre Arbeit abgeschlossen hat.

Es ist auch wichtig, die LongestRunningGCProcess Metrik genau zu überwachen CloudWatch. Anhand dieser Metrik können Sie sich ein Bild davon machenGCRuntimeStats, wie effizient die Speicherbereinigung in Ihrem gesamten System funktioniert.

Für die Überwachung auf Sammlungsebene

Konzentrieren Sie sich auf zwei wichtige Kennzahlen. Zunächst empfehlen wir, den MvccIdAgeScale Wert jeder Sammlung im Auge zu behalten. Steigende Werte deuten darauf hin, dass MVCC IDs altern und möglicherweise Aufmerksamkeit erfordern. Zweitens sollten Sie überwachenGCRuntimeStats, ob die Müllabfuhr ungewöhnlich lange dauert oder sich über mehrere Tage erstreckt. 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 AvailableMVCCId fällt?

Wenn Ihre AvailableMVCCId 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. Auf diese Weise kann Ihre Anwendung ihren normalen Betrieb fortsetzen und gleichzeitig dem Garbage Collector die zusätzliche Leistung 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 MvccIdAgeScale Metrik, welche spezifischen Sammlungen ältere MVCCs enthalten IDs , die bearbeitet werden müssen. 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 AvailableMVCCId Metrik genau zu beobachten, um sicherzustellen, dass Ihre Maßnahmen die gewünschte Wirkung haben. Ihr Cluster gilt als fehlerfrei, sobald der AvailableMVCCId 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.