ähnliche Frage: High Global Lock% auf Mongodb
Überblick
Wir haben ein Replikat für die Produktionskonfiguration in Version 2.4.8 Mongodb, das auf fünf 4-Core-VMs mit 28 GB RAM und Standard-Azure-Datadisk-Festplatten unter 64-Bit-CentOS 6 ausgeführt wird. Die CPU-Auslastung beträgt ca. 15% pro Sekundärteil. Die CPU-Auslastung beträgt ~ 5-10% auf der Primärseite. Wir haben derzeit Probleme mit der hohen globalen Schreibsperre und dem Hintergrund-Flush-Durchschnitt auf unserer Primärseite. Unsere globale Schreibsperre liegt bei unserer primären Schreibsperre zwischen 30 und 40%, obwohl wir nur ~ 200 Einfügen / Aktualisieren / Löschen pro Sekunde haben (siehe MMS-Ausgabe unten). Wir haben auch festgestellt, dass unser Hintergrund-Flush-Durchschnitt zwischen 2 und 15 Sekunden liegt. Leider verursacht dies eine ernsthafte Anzahl langsamer Abfragen (bis zu 50 Aktualisierungen / Einfügungen> 100 ms pro Sekunde). Wir haben über Sharding nachgedacht, sind jedoch der Meinung, dass Mongodb eine bessere Leistung erbringen sollte.
Testen
Dies sagt mir, dass wir Probleme beim Schreiben auf unsere Festplatten haben, aber das Ausführen eines einfachen iostat zeigt, dass unsere Auslastung auf SDC (der Festplatte, auf die wir schreiben) NICHT maximal ist und zwischen 20 und 40% liegt:
$ iostat -x 1Das Ergebnis für 4 Sekunden:
Linux 2.6.32-279.14.1.el6.openlogic.x86_64 (mongodb3-wus) 05/08/2014 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
5.28 0.00 1.82 5.50 0.00 87.40
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.05 0.04 0.06 0.11 3.25 1.23 26.13 0.00 18.07 14.87 0.25
sdc 0.02 216.57 1.70 95.83 216.22 3106.45 34.07 9.27 95.07 4.32 42.11
sdb 0.00 11.35 0.01 0.56 0.05 95.25 169.44 0.01 18.44 0.11 0.01
avg-cpu: %user %nice %system %iowait %steal %idle
2.56 0.00 2.05 0.00 0.00 95.38
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 15.00 0.00 624.00 41.60 0.20 11.80 13.47 20.20
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
avg-cpu: %user %nice %system %iowait %steal %idle
3.07 0.00 3.07 0.26 0.00 93.61
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 3.00 15.00 24.00 352.00 20.89 0.25 15.17 13.44 24.20
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
avg-cpu: %user %nice %system %iowait %steal %idle
3.33 0.00 1.79 0.77 0.00 94.10
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 11.00 0.00 17.00 0.00 768.00 45.18 0.26 15.18 14.35 24.40
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Ich habe auch einen einfachen Lasttest mit dd durchgeführt:
dd if=/dev/zero of=/dev/sdc1 count=512 bs=1024kDas Ergebnis dieses Tests zeigte, dass die Schreibgeschwindigkeit ~ 840 MB / s beträgt:
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.638451 s, 841 MB/s
Ulimit-Ergebnisse für Mongodb:
[mongod #8066 -- limits]
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 10485760 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 224341 224341 processes
Max open files 20000 20000 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 224341 224341 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
MMS, Mongostat, Mongotop für die Grundschule
Ich habe auch unsere MMS-Ausgabe-, Mongostat- und Mongotop-Ausgaben unten angegeben:
! MMS: MMS-Ausgabe hier klicken
Mongostat:
connected to: 127.0.0.1:27019
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn set repl time
26 41 95 *0 294 178|0 0 52.4g 107g 25.1g 0 chronicle:5.6% 0 65|2 1|4 45k 136k 486 rs0 PRI 23:15:18
96 158 524 *0 1266 783|0 0 52.4g 107g 25.1g 1 chronicle:82.9% 0 0|0 0|0 235k 759k 486 rs0 PRI 23:15:19
33 62 109 *0 637 253|0 0 52.4g 107g 25.1g 0 local:7.2% 0 0|0 0|0 78k 208k 486 rs0 PRI 23:15:20
58 89 153 *0 920 321|0 0 52.4g 107g 25.1g 0 local:16.1% 0 0|0 0|1 113k 569k 486 rs0 PRI 23:15:21
55 95 138 *0 887 322|0 0 52.4g 107g 25.1g 0 chronicle:20.3% 0 0|0 0|0 111k 297k 486 rs0 PRI 23:15:22
24 59 81 *0 217 174|0 0 52.4g 107g 25.1g 1 .:88.5% 0 23|0 0|1 46k 141k 486 rs0 PRI 23:15:23
51 64 136 *0 760 263|0 0 52.4g 107g 25.1g 0 chronicle:17.1% 0 0|0 0|0 93k 266k 486 rs0 PRI 23:15:24
42 60 129 *0 695 288|0 0 52.4g 107g 25.1g 0 local:7.3% 0 0|0 0|0 90k 253k 486 rs0 PRI 23:15:25
33 55 99 *0 693 215|0 0 52.4g 107g 25.1g 1 local:3.1% 0 0|0 0|0 76k 455k 486 rs0 PRI 23:15:26
45 70 95 *0 763 250|0 0 52.4g 107g 25.1g 1 local:9.0% 0 0|0 0|0 88k 225k 486 rs0 PRI 23:15:27
Mongotop:
connected to: 127.0.0.1:27019
ns total read write 2014-05-07T23:09:17
chronicle.ledgers 93ms 0ms 93ms
local.oplog.rs 47ms 47ms 0ms
cliqueme.sites 13ms 0ms 13ms
chronicle.analytics 4ms 0ms 4ms
chronicle_test.system.indexes 0ms 0ms 0ms
chronicle_test.system.namespaces 0ms 0ms 0ms
chronicle_test.system.users 0ms 0ms 0ms
ns total read write 2014-05-07T23:09:18
chronicle.ledgers 101ms 0ms 101ms
local.oplog.rs 66ms 66ms 0ms
cliqueme.cliques 19ms 0ms 19ms
chronicle.analytics 6ms 0ms 6ms
cliqueme.sites 4ms 0ms 4ms
local.slaves 1ms 0ms 1ms
cliqueme.notifications 0ms 0ms 0ms
cliqueme.messages 0ms 0ms 0ms
ns total read write 2014-05-07T23:09:19
local.oplog.rs 66ms 66ms 0ms
chronicle.ledgers 52ms 0ms 52ms
chronicle.analytics 24ms 0ms 24ms
cliqueme.cliques 7ms 0ms 7ms
cliqueme.sites 4ms 0ms 4ms
local.slaves 1ms 0ms 1ms
cliqueme.notifications 0ms 0ms 0ms
cliqueme.messages 0ms 0ms 0ms
ns total read write 2014-05-07T23:09:20
chronicle.ledgers 1842ms 0ms 1842ms
cliqueme.sites 885ms 0ms 885ms
cliqueme.cliques 70ms 0ms 70ms
local.oplog.rs 55ms 55ms 0ms
chronicle.analytics 5ms 0ms 5ms
local.slaves 1ms 0ms 1ms
cliqueme.notifications 0ms 0ms 0ms
cliqueme.messages 0ms 0ms 0ms
ns total read write 2014-05-07T23:09:21
chronicle.ledgers 84ms 0ms 84ms
local.oplog.rs 64ms 64ms 0ms
cliqueme.sites 41ms 0ms 41ms
cliqueme.cliques 11ms 0ms 11ms
chronicle.analytics 4ms 0ms 4ms
chronicle_test.system.indexes 0ms 0ms 0ms
chronicle_test.system.namespaces 0ms 0ms 0ms
chronicle_test.system.users 0ms 0ms 0ms
ns total read write 2014-05-07T23:09:22
chronicle.ledgers 276ms 0ms 276ms
local.oplog.rs 90ms 90ms 0ms
cliqueme.cliques 16ms 0ms 16ms
chronicle.analytics 6ms 0ms 6ms
cliqueme.sites 4ms 0ms 4ms
local.slaves 1ms 0ms 1ms
cliqueme.notifications 0ms 0ms 0ms
cliqueme.messages 0ms 0ms 0ms
Hat jemand Vorschläge, wie wir diese Leistung optimieren können? Wir haben gehört, dass einige Leute im Standalone-Modus bis zu 2K-Schreibvorgänge pro Sekunde ausführen können. Würde ein Wechsel von HDD zu RAID oder SSD dies möglicherweise lösen?
Wir möchten Sharding als letzten Ausweg verwenden.
UPDATE: Wir konnten dieses Problem immer noch nicht lösen, aber weil wir eine Lösung brauchten, sind wir schnell in einen Sharded-Cluster umgezogen. Wir möchten das Problem immer noch herausfinden, da es uns im Sharded-Cluster immer noch betrifft.
Antworten:
Ihre Mongo-Statistik zeigt eine höhere Anzahl von Updates als Einfügungen. Eine Sache, die zu Problemen mit hoher Schreibsperre führen kann, ist, wenn Ihre Aktualisierungen normalerweise die Dokumentgröße erhöhen und das Dokument in die Datendatei verschieben. Wir sind selbst darauf gestoßen, aber wir haben zu der Zeit mit Mongo-Unterstützung zusammengearbeitet, um herauszufinden, sodass ich mich nicht erinnere, welche Metrik oder Statistik Ihnen sagen würde, dass dies der Fall ist. Dies wäre wahrscheinlich nur dann ein Problem, wenn Ihre Dokumentgrößen sehr groß wären. Am Ende haben wir ein Sub-Array aufgeteilt, das immer zu einer eigenen Sammlung hinzugefügt wurde, sodass wir nur neue Dokumente hinzugefügt haben, anstatt ein vorhandenes zu ändern.
Das usePowerOf2Sizes-Flag in der Sammlung kann ebenfalls dazu beitragen, dies zu verringern, indem den Dokumenten Raum für Wachstum gegeben wird. Dies ist anscheinend die Standardeinstellung für 2.6, aber Sie müssten sie aktivieren, wenn Sie noch nicht für 2.6 sind. Die hier beschriebene Einstellung: http://docs.mongodb.org/manual/reference/command/collMod/
quelle