Question

我有一个带有自定义_id和500M +文档的mongodb集合。 _id索引的大小是≈25Gb，整个集合是≈125Gb。服务器有96 Gb RAM。读取活动仅是_id的范围查询。 Explain（）显示查询使用索引。 Mongo在负载测试开始后一段时间内工作得相当快，并且在一段时间后变慢。我可以在日志中看到很多这样的条目：

[conn116] getmore csdb.archive query：{_ id：{$ gt：2812719756651008，$ lt：2812720361451008}} cursorid：444942282445272280 ntoreturn：0 keyUpdates：0 numYields：748 lock（micros）r ：7885031 nreturned：40302 reslen：1047872 10329ms

一段db.currentOp（）：

"waitingForLock" : false,
                        "numYields" : 193,
                        "lockStats" : {
                                "timeLockedMicros" : {
                                        "r" : NumberLong(869051),
                                        "w" : NumberLong(0)
                                },
                                "timeAcquiringMicros" : {
                                        "r" : NumberLong(1369404),
                                        "w" : NumberLong(0)
                                }
                        }

什么是锁（微）r？我该怎么做才能减少它？

Answer 1

什么是locks(micros) r？

读取锁定的时间（以微秒为单位）。

R - 全局读锁
W - 全局写锁
r - 数据库特定的读锁定
w - 数据库特定的写锁定

我该怎样做才能减少它？

How does sharding affect concurrency?

通过在多个mongod实例上分发集合，Sharding可以提高并发性，允许分片服务器（即mongos进程）同时对各个下游mongod实例执行任意数量的操作。
Diagnosing Performance Issues (Locks)

MongoDB使用锁定系统来确保数据集的一致性。但是，如果某些操作长时间运行，或者队列形成，则性能将随着请求和操作等待锁定而变慢。与锁相关的减速可能是间歇性的。要查看锁定是否影响了您的效果，请查看globalLock输出的serverStatus部分中的数据。如果globalLock.currentQueue.total一直很高，那么大量请求可能正在等待锁定。这表明可能会影响性能的并发问题。

如果globalLock.totalTime相对于正常运行时间较高，则数据库已存在锁定状态很长一段时间。如果globalLock.ratio也很高，MongoDB可能正在处理大量长时间运行的查询。长查询通常是由多种因素造成的：索引的无效使用，非最佳模式设计，较差的查询结构，系统架构问题或RAM不足导致页面错误和磁盘读取。
How We Scale MongoDB（垂直）

可悲的是，MongoDB本身通常会在服务器容量耗尽之前成为瓶颈。写锁定几乎总是最大的问题（尽管单个MongoDB进程可以利用多少IO容量存在实际限制）。

Mongodb读锁

1 个答案: