MongoDB读锁

Question

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

[conn116] getmore csdb.archive 查询:{ _id: { $gt: 2812719756651008, $lt: 2812720361451008 } } cursorid:444942282445272280 ntoreturn:0 keyUpdates:0 numYields: 748 locks(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)
                                }
                        }

什么是locks(micros) r？我能做些什么来减少它？

Answer 1

What is locks(micros) r?

读取锁的持有时间(以微秒为单位)。

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

---

What can I do to cut it down?

• How does sharding affect concurrency?

  Sharding improves concurrency by distributing collections over multiple mongod instances, allowing shard servers (i.e. mongos processes) to perform any number of operations concurrently to the various downstream mongod instances.

• Diagnosing Performance Issues (Locks)

  MongoDB uses a locking system to ensure data set consistency. However, if certain operations are long-running, or a queue forms, performance will slow as requests and operations wait for the lock. Lock-related slowdowns can be intermittent. To see if the lock has been affecting your performance, look to the data in the globalLock section of the serverStatus output. If globalLock.currentQueue.total is consistently high, then there is a chance that a large number of requests are waiting for a lock. This indicates a possible concurrency issue that may be affecting performance.

  If globalLock.totalTime is high relative to uptime, the database has existed in a lock state for a significant amount of time. If globalLock.ratio is also high, MongoDB has likely been processing a large number of long running queries. Long queries are often the result of a number of factors: ineffective use of indexes, non-optimal schema design, poor query structure, system architecture issues, or insufficient RAM resulting in page faults and disk reads.

• How We Scale MongoDB (垂直)

  Sadly, MongoDB itself will usually become a bottleneck before the capacity of a server is exhausted. Write lock is almost always the biggest problem (though there are practical limits to how much IO capacity a single MongoDB process can take advantage of).