MongoDB verlangsamt alle 2 Stunden und 10 Minuten genau
In den letzten 3 Monaten wurde mein MongoDB-Server sehr langsam alle 2 Stunden und 10 Minuten sehr genau.
Meine Serverkonfiguration:
- 3 Replikat-Set, und für die Zwecke der Datensicherung hat eine von ihnen 3600 Sekunden Verzögerung.
- Keine Slave-Server zu den 3 Mastern in der Replikatgruppe.
- Verwenden Sie mongoose + node.js, um Ruhe-API bereitzustellen.
- Ungefähr 9 Lesevorgänge und 1,5 Schreibvorgänge pro Sekunde im Durchschnitt in den 24 Stunden Statistikdaten.
Was ich getan habe nach dem Durchsuchen von stackoverflow und google:
- Starten Sie den Server neu. KANN das langsame Intervall 2 Stunden und 10 Minuten NICHT ändern
- Erstelle einen Index für alle Felder, die ich abfrage, keine Auswirkung
- Löschen Sie die Datendatei auf einem Server und verwenden Sie einen anderen zum Wiederherstellen und löschen Sie dann die Option aohter und recovery, ohne Auswirkungen
- Primärer Server verschieben, keine Auswirkungen
- Führe 'currentOps' aus, wenn die Datenbank langsam ist, ich kann eine große Anzahl von Abfragen dort hängen sehen, zu viele Protokolle, um sie hier einzufügen, aber habe keine abnormalen Abfragen gesehen.
- Überprüfen Sie in der Mongo-Konsole "serverStatus", wenn die Datenbank langsam ist. Der Befehl wartet, bis die Datenbank wiederhergestellt ist.
- Keine Speicherauslastung von "top" -Befehl erhöht, wenn die Datenbank langsam ist.
- Rest API, die nicht auf die Datenbank zugreifen funktioniert gut.
Ich denke, da könnte etwas blockieren, ist die wahrscheinlichste Ursache, dass es einen Index erstellen kann. Es gibt etwas Besonderes in meiner Datenbank:
- Ich habe ungefähr 14000 Sammlungen in einer Datenbank und nehme zu. Es kann 1 bis 3000 Datensätze in einer Sammlung geben.
- Sowohl die Anzahl der Sammlungen als auch die Anzahl der Datensätze werden dynamisch erhöht.
- Indexfelder werden beim Erstellen einer neuen Sammlung angegeben.
Ich war von diesem Problem seit drei Monaten besessen. Alle Kommentare / Vorschläge werden sehr geschätzt!
Hier sind einige Protokolle aus meiner Protokolldatei:
Fr Jul 5 15:20:11 .040 [conn2765] serverStatus war sehr langsam: {after basic: 0, nach: 0, nach backgroundFlushing: 0, nach Verbindungen: 0, after Cursor: 0, nach dur: 0, nach extra_info: 0, nach globalLock: 0, nach indexCounters: 0, nach Locks: 0, nach Netzwerk: 0, nach Opcounters: 0, nach opcountersRepl: 0, nach recordStats: 222694, nach repl: 222694, am Ende: 222694}
Fr Jul 5 17:30:09 .367 [conn4711] serverStatus war sehr langsam: {after basic: 0, nach der Bestätigung: 0, nach backgroundFlushing: 0, nach den Verbindungen: 0, after Cursor: 0, nach dur: 0, nach extra_info: 0, nach globalLock: 0, nach indexCounters: 0, nach Locks: 0, nach Netzwerk: 0, nach Opcounters: 0, nach opcountersRepl: 0, nach recordStats: 199498, nach repl: 199498, Ende: 199528}
Fr Jul 5 19:40:12 .697 [conn6488] serverStatus war sehr langsam: {after basic: 0, nach der Aktivierung: 0, nach backgroundFlushing: 0, nach den Verbindungen: 0, after cursors: 0, nach dur: 0, nach extra_info: 0, nach globalLock: 0, nach indexCounters: 0, nach Sperren: 0, nach Netzwerk: 0, nach opcounters: 0, nach opcountersRepl: 0, nach recordStats: 204061, nach repl: 204061, am Ende: 204081}
Hier ist der Screenshot meines Pingdom-Berichts, der Server alle 4 Stunden alle 2 Stunden und 7 Minuten heruntergefahren. Zu Beginn der Server 2 Minuten alle 2 Stunden und 6 Minuten.
[EDIT 1] Mehr Monitor-Ergebnis vom Host-Provider: CPU http://i.minus.com/iZBNypzLSLRR.png DiskIO http://i.minus.com/ivgrHr0Ghoz92.png Verbindungen http://i.minus.com/itbfYq0SSMlNs.png Die periodisch erhöhten Verbindungen sind darauf zurückzuführen, dass Verbindungen warten, und der Zählwert für die aktuelle Verbindung wird akkumulieren, bis die Datenbank entsperrt wird. Dies ist nicht auf großen Traffic zurückzuführen.
3 Antworten
Wir haben ein spezifisches 2:10 Problem gefunden. In unserem Fall war es eine Ausführung von dbStats per MMS. Wir mussten das Cluster aktualisieren und das Problem wurde gelöst.
Ich hatte ein ähnliches Problem. Ich würde mit mongostat / mongotop anfangen und dich von dort aus arbeiten. Identifizieren Sie die vorherrschende Arbeitslast mit mongostat und ermitteln Sie anschließend, welche Sammlung diese Aktivität verursacht.
Für meinen speziellen Fall habe ich einen Cron-Job, der obsoletes Datensätze löscht. Es stellt sich heraus, dass die Art und Weise, auf die der Replikatsatz diese Befehle propagiert, extrem ressourcenintensiv ist. Zum Beispiel würde ich 3m Datensätze aus einer Sammlung löschen, die auf dem Replikat-Set-Master passiert. Aus irgendeinem Grund macht diese Propagation alle Secondaries in der nachfolgenden Propagation intensiv.
Wenn Sie die Dinge in db.currentOp sehen können, würde ich mich auf diejenigen konzentrieren, die eine lange Laufzeit haben und versuchen, die Ursache durch Beseitigung von dort zu lokalisieren.
Ich hoffe, das hilft.
Ich denke du meinst ein Replicaset mit 3 Knoten anstelle von "3 replica set".
Wenn das Problem immer noch auftritt. Hier ist meine Meinung:
-
Da Sie Ihren Server in linode.com betreiben. Ihr Server ist eine virtuelle Maschine und Sie teilen Ressourcen mit anderen. Die periodische Verlangsamung kann darauf zurückzuführen sein, dass andere regelmäßig mit der Plattenlast arbeiten. Da Sie schon so viele verschiedene Möglichkeiten kennengelernt haben, ist dies für Sie eine Option, auch wenn es ein wenig Aufwand erfordert.
-
Dies wird definitiv durch einen Job verursacht, der von mongodb oder Ihrem System ausgeführt wird. Bitte versuchen Sie, nach einem Job zu suchen, der regelmäßig ausgeführt wird. Versuchen Sie beispielsweise, die Verzögerung von 3600 Sekunden auf einem Ihrer sekundären zu entfernen. Auch das ist nicht 2 Stunden und 10 Minuten, aber das kann ein Auslöser sein.
Ich kann meine Vorschläge nicht im Kommentar posten, da es mir nicht erlaubt ist. Ich poste das als Antwort.