当运行mongostat查看我们的mongo数据库时，我会经常看到locking的％数字跳跃，有时高达80％。 以下是一些示例行：
insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn time 0 10 7 0 0 17 0 2.27g 5g 1.63g 0 0.1 0 0|0 0|0 22k 7k 83 15:46:10 0 21 7 1 0 23 0 2.27g 5g 1.73g 0 0.1 0 0|0 0|1 11k 424k 83 15:46:11 0 28 10 3 0 28 0 2.27g 5g 1.73g 0 26.9 0 0|0 0|0 33k 196k 83 15:46:12 0 17 6 3 0 13 0 2.27g 5g 1.72g 0 18.2 0 0|0 0|0 11k 10k 83 15:46:13 0 18 5 1 0 11 0 2.27g 5g 1.73g 0 0.1 0 0|0 0|0 23k 362k 83 15:46:14 mongostat的帮助表示这是
locking – 全局写入locking的时间百分比
我的理解是写locking整个数据库。 如果我在同一个mongo服务器上有两个数据库（A和B），会写在A块上写在B上？ 在一个数据库中有一半的时间意味着它会显示25％（比如使用一个双核心的一个核心的一半），还是会显示50％？
是的，MongoDB使用全局写入锁（全服务器范围），所以mongostat报告的“locking％”表示在最后一个采样周期（1秒）内服务器在全局写入locking中花费的总时间 – 对于所有操作在所有dbs上。
当你做更多的写操作，如更新，插入，删除和evals，这个值将会增加。
以上示例中的数字对于独立服务器而言并不令人担忧。
然而，80％的定期读数表明，您可能希望在多个服务器之间平衡您的读写，或者分割您的集合，尽pipe我希望在分区之前解决存储问题。
一般而言，优化的关键在于包括正确和全面的索引，限制结果，使用profiler和explain（）来发现瓶颈，确保正确使用驱动程序（试验游标批量大小可以产生显着的改进）。
高写locking百分比不是performance的唯一标志。 你应该把这个数字和你的写入队列结合起来，这个数字表示插入/更新/插入的次数，并删除排队（总共）获取一个锁的操作。 如果这两个数字一直保持高位，则应该立即解决一个问题。 如果是这样的话，先拉出最上面的慢查询，分析并尝试调整它们。 如果不能进一步调整，请转到在服务器上分配的资源。