Welche Faktoren tragen zum Lock-Prozentsatz bei MongoDB bei?

Wir versuchen, die Verwendung unserer MongoDB-Instanz besser zu optimieren. Wir scheinen routinemäßig hohe Lock-Prozentsätze zu erhalten und versuchen, dies zu minimieren. Hier ist eine Mongostat-Ausgabe:

insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time 
     1    107    186      0       0     196       0  3.06g   7.3g   333m      0     11.2          0       0|0     2|0    66k   224k    85   15:55:22 
     2    102    285      0       0     296       0  3.06g   7.3g   333m      0     15.7          0       0|0     2|0    89k   216k    84   15:55:23 
     2     79    325      0       0     335       0  3.06g   7.3g   333m      0     20.2          0       0|0     3|0    96k   149k    85   15:55:24 
     2     92    193      0       0     203       0  3.06g   7.3g   333m      0     10.9          0       1|1     6|1    63k   149k    86   15:55:25 
     3    102    235      0       0     245       0  3.06g   7.3g   331m      0     14.5          0       0|0     2|0    75k   177k    84   15:55:26 
     3     79    267      0       0     275       0  3.06g   7.3g   331m      0     16.5          0       1|0     2|0    80k   133k    86   15:55:27 
     2     66    219      0       0     226       0  3.06g   7.3g   264m      0     14.3          0       0|0     2|0    66k   112k    88   15:55:28 
     2    100    201      0       0     211       0  3.06g   7.3g   334m      0     10.2          0       0|0     3|0    67k   142k    87   15:55:29 
     3    118    227      0       0     244       0  3.06g   7.3g   322m      0     13.8          0       3|1     6|1    78k   150k    87   15:55:30 
     2    112    189      0       0     198       0  3.06g   7.3g   334m      0     10.8          0       0|1     2|2    64k   213k    87   15:55:31 
     2     80    266      0       0     278       0  3.06g   7.3g   246m      0     15.8          0       0|1     3|1    82k   179k    86   15:55:32 
     1     82    307      0       0     314       0  3.06g   7.3g   334m      0     18.1          0       0|0     2|0    89k   158k    86   15:55:33 
     2     94    278      0       0     285       0  3.06g   7.3g   334m      0     17.1          0       0|0     0|0    83k   184k    86   15:55:34 
     3    101    246      0       0     256       0  3.06g   7.3g   332m      0     14.2          0       0|0     1|0    82k   179k    86   15:55:35 
     3     99    203      0       0     213       0  3.06g   7.3g   334m      0     12.5          0       0|0     2|0    67k   154k    88   15:55:36 
     2    115    174      0       0     189       0  3.06g   7.3g   335m      0       11          0       1|0     3|0    63k   172k    88   15:55:37 
     2     97    199      0       0     209       0  3.06g   7.3g   335m      0     10.3          0       0|0     2|0    65k   192k    87   15:55:38 
     2    103    366      0       0     373       0  3.06g   7.3g   334m      0     23.5          0       1|4     3|4   107k   256k    85   15:55:39 
     2    105    338      0       0     349       0  3.06g   7.3g   334m      0     22.9          0       0|0     1|0   101k   207k    83   15:55:40 

Dies ist dank besserer Indizierung viel besser als früher. Wir haben jedoch eindeutig mehr zu tun. Dinge über diesen Datensatz:

• Hardware ist eine 4-Prozess-Box, der Lastdurchschnitt liegt im Allgemeinen zwischen 1,3 und 1,9
• 4 GB RAM
• Der SAN-gestützte Speicher meldet Latenzen mit einem Spitzenwert von 35 ms, im Allgemeinen jedoch meistens zwischen 5 m und 20 ms.
• E / A-Operationen sind sehr gering
• Die Zahlen 'qr' und 'qw' deuten darauf hin, dass wir keine großen Warteschlangen haben.

Wir verwenden Mongo, um Metadaten zu verfolgen, während Dokumente unsere Verarbeitungsplattform passieren. Für jedes aktuelle Dokument, das wir haben, wird ein Mongo-Dokument erstellt (tatsächliche Dokumente sind alte Office-Dateien). Jede Verarbeitungsstufe fragt einige Informationen ab und schreibt dann Informationen zurück (manchmal ziemlich viel davon). Abhängig von den Daten, mit denen wir arbeiten, kann es viele Phasen geben.

Dies ist eine aktualisierungsintensive Arbeitslast, daher ist der Prozentsatz der Sperren eine wichtige Skalierungsstatistik. Wir haben noch nicht gesplittert, zum großen Teil, weil wir sehen müssen, wie weit eine einzelne Instanz skalieren kann, bevor wir sharden müssen .

Welche anderen Bereiche müssen wir untersuchen, um den Prozentsatz der Sperren zu verringern, oder müssen wir nur gegen die Wand stoßen und Scherben bilden?

Das sind interessante Statistiken. Ich denke, Sie leiden möglicherweise unter einer Zunahme der Dokumentgröße bei Ihren Updates, bei denen das Dokument an eine neue Stelle auf der Festplatte kopiert werden muss. Wenn dies tatsächlich der Fall ist, können Sie möglicherweise einen Teil dieses Sperrprozentsatzes wiederherstellen, indem Sie Ihre Dokumente manuell auffüllen. Es erhöht die Komplexität beim ersten Einfügen, ist aber nicht schlecht. Siehe dieses Dokument aus den offiziellen Dokumenten: http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-ManualPadding

Nur eine Idee...