Mongodb
高背景刷新平均mongodb
類似問題：Mongodb 上的 High Global Lock %
概述
我們在 v2.4.8 mongodb 中有一個生產設置副本集，執行在五個 4 核、28gb RAM 虛擬機上，標準 azure datadisk HDD 在 64 位 CentOS 6 上執行。我們以大約 600-700 ops/sec/secondary 的速度在輔助節點上分配讀取。每個輔助節點的 CPU 使用率約為 15%。主伺服器上的 CPU 使用率約為 5-10%。我們目前在我們的主節點上遇到高全域寫入鎖定和後台刷新平均值的問題。儘管每秒只有大約 200 次插入/更新/刪除，但我們的主節點上的全域寫入鎖定在 30-40% 之間（請參閱下面的 MMS 輸出）。我們還注意到我們的後台刷新平均在 2 到 15 秒之間。不幸的是，這會導致大量緩慢的查詢（每秒最多 50 次更新/插入 > 100 毫秒）。我們考慮過分片，但覺得 mongodb 的性能應該比這更好。
測試
這告訴我，我們在寫入 HDD 時遇到問題，但執行一個簡單的 iostat 顯示我們在 sdc（我們正在寫入的磁碟）上的使用率沒有達到最大值，並且在 20% 到 40% 之間：
$ iostat -x 14秒的結果：
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我還使用 dd 執行了一個簡單的負載測試：
dd if=/dev/zero of=/dev/sdc1 count=512 bs=1024k該測試的結果表明寫入速度約為 840 MB/s：
512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 0.638451 s, 841 MB/smongodb的ulimit結果：
[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 usMMS、Mongostat、Mongotop 用於初級
我還在下面提供了我們的 MMS 輸出、mongostat 和 mongotop 輸出：
!MMS：彩信輸出點擊這裡
蒙古國：
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蒙戈托普：
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有人對我們如何優化此性能有任何建議嗎？我們聽說有些人在單機中可以達到每秒 2K 的寫入量？從 HDD 切換到 RAID 或 SSD 可能會解決這個問題嗎？
我們希望使用分片作為最後的手段。
更新：我們仍然無法解決這個問題，但是因為我們需要一個快速的解決方案，所以我們已經轉移到了一個分片集群。我們仍然想找出問題所在，因為它仍然影響著分片集群中的我們。
您的 mongo 統計數據顯示更新數量高於插入數量。可能導致高寫入鎖定問題的一件事是，如果您的更新通常會增加文件大小並導致文件在數據文件中移動。我們自己也遇到了這個問題，但當時我們正在與 mongo 支持人員合作以解決這個問題，所以我不記得是什麼指標或統計數據會告訴你這種情況。如果您的文件尺寸非常大，這可能只是一個問題。我們最終拆分了一個子數組，該子數組總是被添加到它自己的集合中，這樣我們就只是添加新文件而不是修改現有文件。
集合上的 usePowerOf2Sizes 標誌也可以通過為文件提供增長空間來幫助緩解這種情況。這顯然是現在 2.6 的預設設置，但如果您還沒有使用 2.6，則需要將其打開。此處描述的設置：http: //docs.mongodb.org/manual/reference/command/collMod/