Fehlersuche bei der Leistung für Databases for MongoDB

Dieser Leitfaden hilft Ihnen bei der Identifizierung und Behebung von Leistungsproblemen in Ihrer Databases for MongoDB-Bereitstellung, die auf IBM Cloud läuft und von MongoDB unterstützt wird.

Weitere Informationen zur Lösung von Leistungsproblemen finden Sie im Folgenden:

Wenn Ihre Anwendungen mit langsamen Antworten, Timeouts oder inkonsistenter Datenbankleistung zu kämpfen haben, sollten Sie die folgenden Schritte und Informationen beachten.

Symptome von Leistungsproblemen

Sie können einige der folgenden Symptome beobachten, die auf Leistungsprobleme hinweisen:

  • Erhöhte Latenzzeit der Anwendung
  • Langsame Abfrageprotokolleinträge
  • Hohe CPU- oder Speicherauslastung
  • Erhöhte Festplatten-Latenzzeit
  • Replikationsverzögerung
  • Verbindungszeitlimits

Führen Sie die folgenden Schritte aus, um die Ursache der Probleme zu ermitteln:

Schritt 1: Überprüfung der Ressourcenauslastung

  1. Melden Sie sich bei der Konsole IBM Cloud an und navigieren Sie zu Ihrer Bereitstellung MongoDB.

  2. Überprüfen Sie den Abschnitt " Überwachung ":

    • CPU-Auslastung
    • Speicherbelegung
    • Festplatten-IOPS und Latenzzeit
    • Aktive Verbindungen

Worauf Sie achten sollten:

  • CPU konstant über 75%
  • Speicherplatz konstant über 80%
  • Latenzzeit der Festplatte nimmt mit der Zeit zu
  • Verbindungen, die sich den Plangrenzen nähern

Empfohlene Maßnahmen:

  • Erhöhen Sie den Speicherplatz oder die IOPS, wenn die Festplattenlatenz hoch ist.
  • Überprüfen Sie die Arbeitslastspitzen in Ihrer Anwendung.

Wenn die Ressourcennutzung über längere Zeiträume hinweg erhöht bleibt, wird eine Skalierung empfohlen.

Schritt 2: Identifizierung langsamer Abfragen

Langsame Abfragen sind eine der häufigsten Ursachen für Leistungseinbußen.

  1. Aktivieren Sie die Profilerstellung:

    db.setProfilingLevel(1, { slowms: 100 })

  2. Überprüfen Sie die letzten langsamen Operationen:

    db.system.profile.find().sort({ ts: -1 }).limit(20)

  3. Analysieren Sie die Abfrageausführung:

    db.collection.find({ ... }).explain("executionStats")

Worauf Sie achten sollten:

  • COLLSCAN (Auflistungs-Scan anstelle von Index-Verwendung)
  • Hoch totalDocsExamined im Vergleich zu nReturned

Empfohlene Maßnahmen:

  • Erstellen Sie geeignete Indizes.
  • Verwenden Sie zusammengesetzte Indizes für Abfragen mit mehreren Feldern.
  • Stellen Sie sicher, dass die Aggregationspipelines mit $match beginnen.
  • Vermeiden Sie große skip() Seitenumbrüche.

Schritt 3: Überprüfung der Verbindungsnutzung

Hohe oder schlecht verwaltete Verbindungen können die Leistung beeinträchtigen.

Prüfen Sie die Verbindungsstatistiken:

db.serverStatus().connections

Empfohlene Maßnahmen:

  • Verwenden Sie das Connection Pooling in Ihrer Anwendung.
  • Vermeiden Sie es, für jede Anfrage eine neue Verbindung zu öffnen.
  • Nicht verwendete Cursor schließen.

Die Verbindungsgrenzen werden durch Ihren Bereitstellungsplan bestimmt.

Schritt 4: Überprüfung des Zustands der Replikation

Die Verzögerung bei der Replikation kann die Leseleistung und die Aktualität der Daten beeinträchtigen.

Prüfen Sie den Replikationsstatus:

rs.printSecondaryReplicationInfo()

Häufige Ursachen für Verzögerungen:

  • Hoher Schreibdurchsatz
  • Engpässe bei Festplatten
  • Netzwerklatenz

Empfohlene Maßnahmen:

  • Skalierung der Speicherleistung.
  • Überprüfen Sie die Einstellungen für den Schreibschutz.
  • Bei anhaltender Verzögerung auf einen höheren Plan umstellen.

Schritt 5: Überlegungen zum Sharded-Cluster (falls zutreffend)

In den folgenden Situationen kann Sharding erforderlich sein:

  • Arbeitsspeicher ist größer als RAM
  • Maximale IOPS für einen Knoten auch nach Skalierung
  • Horizontale Schreibskalierung ist erforderlich
  • Sammlungen übersteigen 1-2 TB

Weitere Informationen finden Sie unter Leistungsoptimierung und Sharding.

Wenn Ihr Einsatz Sharding verwendet, führen Sie aus:

sh.status()

Prüfen Sie auf:

  • Ungleichmäßige Verteilung der Chunks
  • Jumbo-Brocken
  • Konzentration des Verkehrs auf einen einzigen Splitter

Empfohlene Maßnahmen:

  • Überprüfen Sie die Auswahl der Scherbenschlüssel.
  • Vermeiden Sie monoton ansteigende Scherbenschlüssel.
  • Betrachten Sie gehashte Splitterschlüssel.

Eine unsachgemäße Auswahl der Shard-Schlüssel kann die Leistung bei der Skalierung erheblich beeinträchtigen.

Schritt 6: Nach großen Datenlöschungen

Das Löschen eines erheblichen Prozentsatzes von Daten führt nicht sofort zu einer Verringerung der Festplattennutzung auf Betriebssystemebene.

Mögliche Auswirkungen:

  • Interne Fragmentierung
  • Hohe Festplattenauslastung
  • Geringere Leistung

Empfohlene Maßnahmen:

  • Planen Sie die Verdichtungsarbeiten sorgfältig.
  • Ziehen Sie bei starker Fragmentierung eine Sicherung und Wiederherstellung in Betracht.
  • Halten Sie die Festplattennutzung unter 80-85%.

Planen Sie Wartungstätigkeiten angemessen.

Schritt 7: Prüfen Sie, ob eine Sperre vorhanden ist

Sperrkonflikte können gleichzeitige Vorgänge und den Gesamtdurchsatz stark beeinträchtigen.

  • Prüfen Sie die globale Sperrstatistik:

    db.serverStatus().locks

  • Prüfen Sie die laufenden Vorgänge auf Sperren:

    db.currentOp({
  $or: [
    { waitingForLock: true },
    { "locks.Global": "w" }
  ]
})

  • Analysieren Sie die Wartezeit auf Sperren:

    db.serverStatus().globalLock

Worauf Sie achten sollten:

  • Hohe currentQueue Werte (Leser oder Schreiber).
  • Operationen mit waitingForLock: true.
  • Lang laufende Operationen mit Sperren.
  • Indexerstellung, die Operationen blockiert.

Häufige Ursachen:

  • Langwierige Abfragen ohne geeignete Indizes.
  • Große Schreibvorgänge.
  • Der Index baut auf großen Sammlungen auf.
  • Verwaltungsbefehle (kompakt, repairDatabase ).

Empfohlene Maßnahmen:

  • Beenden Sie lang laufende Vorgänge, falls erforderlich:
    db.killOp(opid)
  • Erstellen Sie Indizes im Hintergrund:
    db.collection.createIndex({ field: 1 }, { background: true })
  • Teilen Sie große Vorgänge in kleinere Partien auf.
  • Planen Sie Wartungsarbeiten in verkehrsarmen Zeiten.
  • Verwenden Sie Lese- und Schreibzugriffsrechte in angemessener Weise.

Schritt 8: Analyse der Arbeitslastmuster

Das Verständnis Ihrer Auslastungsmuster hilft, Optimierungsmöglichkeiten zu erkennen.

  • Betriebszähler prüfen:

    db.serverStatus().opcounters

  • Analysieren Sie die Vorgänge im Laufe der Zeit:

    db.serverStatus().opcountersRepl

  • Identifizieren Sie heiße Sammlungen:

    db.adminCommand({ top: 1 })

  • Überprüfen Sie das Leseverhältnis im Vergleich zum Schreibverhältnis:

    var stats = db.serverStatus().opcounters;
print("Read ratio: " + (stats.query + stats.getmore) / (stats.query + stats.getmore + stats.insert + stats.update + stats.delete));

Worauf Sie achten sollten:

  • Unverhältnismäßige Eingriffe in bestimmte Sammlungen
  • Hohe Lese-Schreib- oder Schreib-Lese-Verhältnisse
  • Plötzliche Spitzen bei der Anzahl der Operationen
  • Zeitabhängige Muster (Spitzenzeiten)

Empfohlene Maßnahmen:

  • Optimieren Sie zuerst häufig genutzte Sammlungen.
  • Erwägen Sie Read Replicas für leseintensive Workloads.
  • Verwenden Sie geeignete Leseeinstellungen.
  • Implementieren Sie eine Zwischenspeicherung für häufig gelesene Daten.
  • Überprüfung der Indizierungsstrategie für aktuelle Sammlungen.
  • Erwägen Sie Sharding für schreibintensive Sammlungen.

Schritt 9: Untersuchen Sie die Speicherbelastung und die Cache-Effizienz

MongoDB's WiredTiger speicher-Engine ist stark auf die Effizienz des Cache angewiesen.

  • Prüfen Sie die Cache-Statistiken von WiredTiger:

    db.serverStatus().wiredTiger.cache

  • Überprüfen Sie die wichtigsten Metriken:

    var cache = db.serverStatus().wiredTiger.cache;
print("Cache size: " + cache["bytes currently in the cache"]);
print("Max cache size: " + cache["maximum bytes configured"]);
print("Pages read into cache: " + cache["pages read into cache"]);
print("Pages written from cache: " + cache["pages written from cache"]);
print("Cache hit ratio: " + (1 - cache["pages read into cache"] / (cache["pages read into cache"] + cache["pages requested from the cache"])));

  • Prüfen Sie auf Räumungsdruck:

    db.serverStatus().wiredTiger.cache["pages evicted by application threads"]

Worauf Sie achten sollten:

  • Cache-Trefferrate unter 95%
  • Hohe Zwangsräumungsraten
  • Cachegröße konstant auf Maximum
  • Anwendungs-Threads, die Räumungen durchführen

Schätzen Sie die Größe des Arbeitssets:

db.serverStatus().wiredTiger.cache["tracked dirty bytes in the cache"]

Empfohlene Maßnahmen:

  • Skalieren Sie auf einen Plan mit mehr Speicher, wenn der Cache ständig voll ist.
  • Überprüfen und Optimieren von Indizes (Entfernen ungenutzter Indizes).
  • Begrenzung der Größe von Ergebnismengen in Abfragen.
  • Verwenden Sie Projektionen, um das Dokument zu verkleinern.
  • Erwägen Sie die Archivierung alter Daten.
  • Überwachen Sie die Entwicklung der Größe der Arbeitsgeräte.

Bewährte Praktiken der Speicherzuweisung

  • Der WiredTiger Cache sollte 50 % des verfügbaren Arbeitsspeichers betragen (Standard).
  • Lassen Sie genügend Speicherplatz für andere Prozesse.
  • Überwachen Sie die Swap-Nutzung, die minimal sein sollte.

Schritt 10: Überprüfen Sie die Einstellungen für die Schreib- und Lesepräferenzen

Die Einstellungen für die Schreib- und Lesepräferenzen haben erhebliche Auswirkungen auf Leistung und Konsistenz.

  • Prüfen Sie die aktuelle Schreibsorge:

    db.getWriteConcern()

  • Überprüfen Sie die Konfiguration des Replikationssets:

    rs.conf()

  • Schreiben Sie Betroffenheitsoptionen:

    Optionen zum Schreiben von Bedenken
    Anliegen schreiben Permanenz Leistung Anwendungsfall
    w: 1 Niedrig Hoch Unkritische Daten, hoher Durchsatz
    w: "majority" Hoch Mittel Standard, ausgewogener Ansatz
    w: <number> Mittel-Hoch Mittel-niedrig Spezifische Anzahl von Replikaten
    j: true Am höchsten Niedrigste Kritische Daten, die eine Journalsynchronisation erfordern

  • Lesen Sie die Einstellungsoptionen:

    Einstellungsoptionen lesen
    Präferenz lesen Konsistenz Leistung Anwendungsfall
    primary Am höchsten Mittel Standard, starke Konsistenz
    primaryPreferred Hoch Mittel-Hoch Rückgriff auf sekundäre
    secondary Eventual Hoch Analytik, Berichterstattung
    secondaryPreferred Eventual Hoch Skalierung lesen
    nearest Eventual Am höchsten Geringste Latenz

  • Prüfen Sie die Lesepräferenz in Ihrer Bewerbung:

    // Example in Node.js driver
db.collection('users').find({}).readPreference('secondary')

Worauf Sie achten sollten:

  • Übermäßig strenge Schreibsperren für nicht kritische Daten
  • Verwendung von primary Lesepräferenz, wenn eventuelle Konsistenz akzeptabel ist
  • Keine Nutzung von Secondaries für leseintensive Workloads

Empfohlene Maßnahmen:

  • Verwenden Sie w: 1 für unkritische Schreibvorgänge mit hohem Durchsatz.
  • Verwenden Sie w: "majority" für wichtige Daten (Standard).
  • Verwenden Sie secondary oder secondaryPreferred für analytische Abfragen.
  • Erwägen Sie nearest für geografisch verteilte Anwendungen.
  • Gleichgewicht zwischen Konsistenzanforderungen und Leistungsanforderungen.
  • Testen Sie verschiedene Konfigurationen unter Last.

Schritt 11: Überwachung der Auswirkungen von Sicherung und Wartung

Backup-Vorgänge und Wartungsaufgaben können die Leistung vorübergehend beeinträchtigen.

IBM Cloud sicherungszeitplan

Databases for MongoDB automatisch ein Backup erstellt. Überprüfen Sie Ihren Sicherungsplan in der Konsole IBM Cloud unter Backups.

Prüfen Sie, ob noch Sicherungsvorgänge laufen:

db.currentOp({
  $or: [
    { op: "command", "command.backup": { $exists: true } },
    { desc: /^conn/ }
  ]
})

Worauf Sie achten sollten:

  • Leistungsverschlechterung während der Sicherungsfenster
  • Erhöhte Festplatten-E/A bei Backups
  • Replikationsverzögerung bei Backups

Empfohlene Maßnahmen:

  • Überwachen Sie die Leistungsmetriken während der Sicherungszeiten.
  • Ziehen Sie eine Skalierung in Betracht, wenn Backups die Leistung dauerhaft beeinträchtigen.
  • Überprüfen Sie die Richtlinien zur Aufbewahrung von Sicherungskopien.
  • Planen Sie einen erhöhten Ressourcenverbrauch während der Wiederherstellungsvorgänge ein.

Bewährte Praktiken bei der Wartung

  • Planen Sie Indexerstellungen in verkehrsarmen Zeiten.
  • Verwenden Sie, wenn möglich, Hintergrundindexe.
  • Überwachung der Replikationsverzögerung während der Wartung.
  • Testen Sie die Wartungsvorgänge zunächst im Nicht-Produktionsbetrieb.
  • Koordinieren Sie sich mit IBM Cloud Wartungsfenster.