it-swarm.com.de

Was passiert, wenn in MongoDB zu viele Einfügungen vorhanden sind? Wie kann sichergestellt werden, dass alle Daten gespeichert werden?

Ich verwende MongoDB, um periodisch gemessene Werte zu speichern. Alle ~ 100 ms wird eine Reihe von Werten als Dokument eingefügt. Es funktioniert gut, aber ich mache mir Sorgen um Leistungsprobleme. (Ich verwende sichere Einsätze, es scheint, als ob dies in PyMongo die Standardeinstellung ist.)

Was passiert, wenn mehr Einfügungen pro Sekunde vorhanden sind, als mongod auf der Festplatte speichern kann? Wird es eine Warnung geben oder wird es einfach lautlos scheitern?

Gibt es eine Methode zur Überwachung der Schreiblast? Ich habe nur db.serverStatus().writeBacksQueued gefunden, das beim Aufruf immer auf false gesetzt ist. Wie kann ich testen, wie viele Daten ich einfügen muss, um die Schreibwarteschlange zu füllen?

mongostat zeigt Sperren an. Sollte ich mir darüber Sorgen machen?

insert  query update delete getmore command flushes mapped  vsize    res faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
  *117     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:6.5%          0       0|0     0|0   124b     6k     2  SLV   09:58:10 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:0.8%          0       0|0     0|0   124b     6k     2  SLV   09:58:11 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:4.2%          0       0|0     0|0   124b     6k     2  SLV   09:58:1

Muss ich mir Sorgen um Schreibsperren machen? Was passiert mit einer Einfügung während eines Schreibsperrzeitraums? Wird es später in die Warteschlange gestellt und gespeichert?

Ich denke über ein einfaches Replikationssetup mit einem Master und einem Slave nach. Sperrt die anfängliche Synchronisierung oder ein Resynchronisierungsprozess die Datenbanken?

(Ich verwende Version 2.4.3.)

Update: Ich denke, ich habe meine eigene Frage teilweise beantwortet. Ich habe es geschafft, mit einer einfachen while-Schleife, die ein kleines Testdokument einfügt, bis zu 12.000 Einfügungen pro Sekunde zu erhalten. Aber qr | qw zeigt immer noch, dass die Lese- und Schreibwarteschlange noch leer ist:

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
 11234     *0      2     *0    1563     1|0       1  21.9g  44.3g  1.22g      0    testdb:58.9%          0       1|0     1|1   797k   980k     6  PRI   10:26:32 
 12768     *0      2     *0    1284     1|0       0  21.9g  44.3g  1.22g      0    testdb:58.0%          0       0|0     0|1   881k     1m     6  PRI   10:26:33 
 12839     *0      2     *0    1231     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.3%          0       0|0     0|1   883k     1m     6  PRI   10:26:34 
 12701     *0      2     *0     910     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   858k     1m     6  PRI   10:26:35 
 12241     *0      2     *0    1206     1|0       0  21.9g  44.3g  1.22g      0    testdb:56.7%          0       0|0     0|0   843k     1m     6  PRI   10:26:36 
 11581     *0      2     *0    1406     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   811k     1m     6  PRI   10:26:37 
  8719     *0      2     *0    1210     1|0       0  21.9g  44.3g  1.22g      0    testdb:43.8%          0       0|0     0|1   618k   762k     6  PRI   10:26:38 
 11429     *0      2     *0    1469     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.6%          0       0|0     0|1   804k   993k     6  PRI   10:26:39 
 12779     *0      2     *0    1092     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.2%          0       1|0     0|1   872k     1m     6  PRI   10:26:40 
 12757     *0      2     *0     436     1|0       0  21.9g  44.3g  1.22g      0    testdb:59.7%          0       0|0     0|1   838k   432k     6  PRI   10:26:41 

Ich nehme an, dies bedeutet, dass Einfügungen allein nicht viele Probleme verursachen: "Warteschlangen neigen dazu, zu spitzen, wenn Sie neben anderen Schreibvorgängen, wie z. B. großen Entfernungen, viele Schreibvorgänge ausführen." (gefunden hier ]

Meine offene Frage: Was passiert mit meinen Daten, wenn sich die Schreibwarteschlange langfristig erhöht?

24
lumbric

Sie haben hier einige Ihrer eigenen Fragen beantwortet, insbesondere haben Sie eine gute Vorstellung vom Aspekt der Schreibsperre in der Gleichung - 12.000 Einfügen/Sek. Bringen Sie zu ~ 60% Schreibsperre. Das ist ein vernünftiges Niveau, um eine konstante Leistung zu erzielen - Sie werden einige Konflikte bekommen und einige Operationen werden etwas langsamer sein, aber Sie möchten sich wirklich bei etwa 80% Sorgen machen - wie bei vielen anderen Dingen, wenn Sie anfangen, mehr als 80% verfügbar zu machen Kapazität werden Sie viel häufiger Probleme treffen.

In Bezug auf andere Engpässe und insbesondere, wie schnell Sie auf die Festplatte schreiben können, kann dies zu Problemen führen. Um jedoch die relevanten Statistiken im Laufe der Zeit zu überprüfen, würde ich empfehlen, [~ # ~] mms [ ~ # ~] installiert mit dem Munin-Node-Plugin , um Ihnen Hardware und IO zu geben Statistiken zusätzlich zu den MongoDB-Statistiken.

Wenn Sie das haben, sind die Metriken, die Sie im Auge behalten möchten:

  • Die durchschnittliche Spülzeit (so lange dauert die periodische Synchronisierung von MongoDB mit der Festplatte)
  • Die IOStats auf der Registerkarte Hardware (insbesondere IOWait)
  • Seitenfehler (Wenn Ihre Festplatte mit Schreibvorgängen beschäftigt ist und Sie Daten lesen müssen, konkurrieren diese um eine knappe Ressource.)

Es ist dann ein bisschen kompliziert, aber hier ist eine Grundidee:

  • Machen Sie sich Sorgen, wenn die durchschnittliche Spülzeit zu steigen beginnt
  • Wenn es in den Bereich von mehreren Sekunden gelangt, sind Sie wahrscheinlich am Limit (obwohl dies vom geschriebenen Datenvolumen und der Festplattengeschwindigkeit abhängt).
  • Wenn es sich 60 Sekunden nähert, wird die Leistung stark beeinträchtigt (die Spülung erfolgt alle 60 Sekunden, sodass sie sich im Wesentlichen in der Warteschlange befinden).
  • Ein hoher IOWait-Wert beeinträchtigt auch die Leistung, insbesondere wenn Sie zu irgendeinem Zeitpunkt von der Festplatte lesen müssen
  • Daher ist es auch wichtig, die Seitenfehlerstufen zu betrachten

Das andere Teil dieses Puzzles, das wir noch nicht erwähnt haben, ist das Tagebuch. Dadurch werden auch Daten auf der Festplatte gespeichert (standardmäßig alle 100 ms). Wenn sich die Daten auf demselben Datenträger befinden, wird die Belastung der Festplatte erhöht. Wenn Sie eine hohe Festplattenauslastung feststellen, ist es daher eine gute Idee, das Journal auf eine andere Festplatte zu verschieben.

Es gibt keine wirklichen "magischen Zahlen", unter denen man bleiben kann. In den meisten Fällen ist alles relativ. Holen Sie sich also eine gute Basis für Ihren normalen Verkehr, prüfen Sie, ob die Dinge im Trend liegen, und testen Sie sie möglicherweise, um festzustellen, wo Ihre Grenzen liegen und wann beginnen sich zu verschlechtern und Sie werden in guter Verfassung sein.

Nach all dem Vorlauf zu einigen Ihrer Fragen:

Was passiert, wenn mehr Einfügungen pro Sekunde vorhanden sind, als mongod auf der Festplatte speichern kann? Wird es eine Warnung geben oder wird es einfach lautlos scheitern?

Wenn Sie anfangen, die Festplatte auf die oben beschriebenen Werte zu belasten, wird sich irgendwann alles verlangsamen und irgendwann (und dies hängt von Zeitüberschreitungen ab, wie leistungsfähig Ihre Hardware ist, wie Sie mit Ausnahmen umgehen) werden Ihre Schreibvorgänge fehlschlagen - wenn Wenn Sie eine neuere Version von Pymongo verwenden, verwenden Sie standardmäßig sichere Schreibvorgänge, die dann fehlschlagen. Wenn Sie etwas paranoider sein möchten, können Sie gelegentlich ein Schreibproblem von j: true ausführen, das darauf wartet, dass OK zurückgegeben wird, bis das Schreiben abgeschlossen ist es in das Tagebuch (dh auf der Festplatte). Dies ist natürlich langsamer als ein normales sicheres Schreiben, aber es ist ein sofortiger Hinweis auf Probleme mit der Festplattenkapazität, und Sie können es verwenden, um andere Vorgänge zu blockieren/in die Warteschlange zu stellen und im Wesentlichen als Drossel zu fungieren, um zu verhindern, dass Ihre Datenbank funktioniert überwältigt.

Ich denke über ein einfaches Replikationssetup mit einem Master und einem Slave nach. Sperrt die anfängliche Synchronisierung oder ein Resynchronisierungsprozess die Datenbanken?

Ich denke, ich habe das Sperren zu Beginn insgesamt behandelt, aber um dieses Stück speziell zu beantworten: Stellen Sie zunächst sicher, dass Sie ein Replikatset verwenden, nicht Master/Slave . Die Master/Slave-Implementierung ist veraltet und wird für die allgemeine Verwendung nicht empfohlen. Da bei der anfänglichen Synchronisierung die Primärdaten in Bezug auf Lesevorgänge, jedoch nicht in Bezug auf Schreibvorgänge etwas belastet werden, sollten Sie in Bezug auf das Sperren in Ordnung sein.

Was passiert mit meinen Daten, wenn sich die Schreibwarteschlange langfristig erhöht?

Wie Sie wahrscheinlich aus der obigen Erklärung ersehen können, hängt die Antwort stark davon ab, wie Sie Ihre Bewerbung schreiben, wie Sie Ihre Schreibvorgänge bestätigen lassen und wie viel Kapazität Ihnen zur Verfügung steht. Sie können im Wesentlichen so sicher sein, wie Sie möchten, wenn Sie in MongoDB auf die Festplatte schreiben, aber es gibt einen Leistungskompromiss, wie in der obigen Diskussion j:true Erwähnt.

Im Allgemeinen möchten Sie Ihren begrenzenden Faktor herausfinden - sei es Sperren, Festplattengeschwindigkeit usw. - und dann die Pegel im Laufe der Zeit verfolgen und skalieren (Sharding) oder erhöhen (bessere Hardware), bevor Sie ein hartes Limit erreichen und Leistungsprobleme feststellen.

Eine letzte Sache, db.serverStatus().writeBacksQueued, ist tatsächlich eine Metrik, die in einer Sharded-Umgebung immer nur ungleich Null ist, und es geht darum sicherzustellen, dass Schreibvorgänge in einen Block während einer Migration angemessen behandelt werden (behandelt werden) vom Writeback-Listener ). Daher ist es hier im Wesentlichen ein roter Hering - nichts mit allgemeinem Schreibvolumen zu tun.

25
Adam C