类似的问题：High Global Lock % on Mongodb
概观
我们在v2.4.8 mongodb中运行了一个生产设置副本,运行在5个4核,28gb RAM VM上,标准的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应该比这更好.
测试
这告诉我,我们在写入硬盘驱动器时遇到问题,但运行一个简单的iostat表明我们对sdc(我们写入的磁盘)的利用率没有达到最大值,介于20％和40％之间：
$iostat -x 1
结果为4秒：
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 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/s
mongodb的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 us
MMS,Mongostat,Mongotop为小学
我还提供了以下的MMS输出,mongostat和mongotop输出：
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
有没有人对如何优化这种性能有任何建议？我们听说有些人每秒可以在独立站中获得高达2K的写入速度吗？从HDD切换到RAID或SSD可能会解决这个问题吗？
我们想使用分片作为最后的手段.
更新：
我们仍然无法解决此问题,但因为我们需要快速解决方案已移至分片群集.我们仍然想弄清楚问题,因为它仍然影响我们在分片群集中.
解决方法:
您的mongo stat显示更多的更新与插入.可能导致高写锁定问题的一件事是,您的更新通常会增加文档大小并导致文档在数据文件中移动.我们自己遇到了这个问题,但当时我们正在使用mongo支持来弄清楚所以我不记得什么度量标准或统计数据会告诉你这种情况.如果您的文档大小非常大,这可能只是一个问题.我们最终将一个总是被添加到其自己的集合中的子数组拆分出来,这样我们就可以添加新文档而不是修改现有文档.
集合上的usePowerOf2Sizes标志还可以通过为文档提供增长空间来帮助缓解这种情况.这显然是2.6的默认值,但如果你还没有使用2.6,你需要打开它.此处描述的设置：http://docs.mongodb.org/manual/reference/command/collMod/
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
