Abfragen mit langer Laufzeit

-Übersicht

Long-running Abfragen können zu clusterweiten Leistungsproblemen führen. Diese Abfragen können den Garbage-Collection-Prozess von Amazon DocumentDB ( Multi-Version Concurrency Control, MVCC) stören, was zur Anhäufung von Dokumenten mit alten Versionen und zu Leistungseinbußen im gesamten Cluster führen kann. Amazon DocumentDB implementiert ein 2-stündiges serverseitiges Timeout als Sicherheitsmechanismus, um zu verhindern, dass außer Kontrolle geratene Abfragen auf unbestimmte Zeit Ressourcen verbrauchen.

Was sind Abfragen mit langer Laufzeit:

• Abfragen, die über einen längeren Zeitraum (in der Regel > 30 Minuten) ausgeführt werden

• Öffnen Sie Cursor, die stundenlang aktiv bleiben (ein Timeout von 2 Stunden gilt nicht, wenn der Cursor aktiv ist)

Auswirkungen auf den Cluster

Abfragen mit langer Laufzeit können den Garbage-Collection-Prozess beeinträchtigen

• Alte Versionen häufen sich an: Garbage Collector kann alte Dokumentversionen nicht zurückfordern

• Aufblähung von Sammlung und Index: Sammlungs- und Indexeinträge häufen sich im Laufe der Zeit an, die Aufblähung nimmt zu, was zu höheren Speicherkosten führen kann.

• CPU- und Speicherauslastung: Die CPU- und Speicherauslastung steigt aufgrund der ineffizienten Verarbeitung einer erhöhten Anzahl alter Dokumentversionen, Indexeinträge und Transaktions-IDs.

Abfrage mit langer Laufzeit → Blocks-GC → Speicherwachstum → CPU- und Speicherauslastung → Mehr lange Abfragen

Überwachen und erkennen

1. Verwenden Sie den Befehl currentOp, um Abfragen mit langer Laufzeit zu finden.

// To find a query running for more than 30 mins
db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: 
            {$or: 
                [{secs_running: {$gt: 1800}},
                 {WaitState: {$exists: true}}]}}],
    cursor: {}
});
      

2. Um Cursor zu finden, die länger als 30 Minuten aktiv sind

// To find cursor which is running more than 30 mins
db.adminCommand({
    "currentOp": true,
    "active": true,
    "$all": true
}).inprog.filter(function(op) {
    return op.desc == "Cursor" && 
           op.secs_running > 1800 && 
           op.active == true;
}).sort((a, b) => b.microsecs_running - a.microsecs_running)
      

3. Überwachung des Fortschritts des Garbage Collectors durch CloudWatch

LongestRunningGCProcess— Dauer des längsten aktiven Garbage-Collection-Vorgangs in Sekunden. Wird jede Minute aktualisiert und verfolgt nur aktive Vorgänge, ausgenommen Prozesse, die innerhalb des einminütigen Zeitfensters abgeschlossen werden.

AvailableMVCCIds-Ein Zähler, der die Anzahl der verbleibenden Schreiboperationen anzeigt, bevor der Wert Null erreicht wird. Wenn dieser Zähler Null erreicht, wechselt Ihr Cluster in den schreibgeschützten Modus, bis IDs zurückgewonnen und recycelt werden. Der Zähler nimmt mit jedem Schreibvorgang ab und steigt, wenn bei der Garbage-Collection alte MVCC-IDs wiederverwendet werden.

Anmerkung

Niedrigere MVCC-IDs und eine längere Garbage-Collection-Dauer sind nicht ausschließlich auf Abfragen mit langer Laufzeit zurückzuführen. Write-intensive Workloads auf Instanzen mit eingeschränkten Ressourcen können auch zu einer verringerten MVCC-ID-Verfügbarkeit und längeren Garbage-Collection-Zyklen führen.

Strategien zur Problembehebung

• Implementieren Sie Abfrage-Timeouts in der Anwendung

• Halten Sie die Cursor nicht für längere Zeit am Leben

• Optimieren Sie die Abfragen für eine bessere Leistung.

• Bevorzugen Sie das Stapeln von Schreibvorgängen