正如WiredTiger存储引擎描述中所说，它通过文档级锁定提供了更好的并发能力。这个帖子：
WiredTiger 可在现代多 CPU 架构上扩展。通过使用各种编程技术（如风险指针、无锁算法、快速锁存和消息传递），WiredTiger 可比其他引擎在每个 CPU 核心上执行更多工作。
出于某种原因，我的用例似乎没有从中受益。我有一个具有许多并发写入（主要是更新）的数据库，这种负载似乎无法克服每秒 2000 次更新的限制。以下是输出mongostat 10：
insert query update delete getmore command % dirty % used flushes vsize res qr|qw ar|aw netIn netOut conn time
3 780 1936 141 42 3|0 0.3 1.0 0 717.0M 289.0M 0|0 1|0 433k 6m 141 17:16:32
磁盘吞吐量未饱和，iostat -x 10输出：
avg-cpu: %user %nice %system %iowait %steal %idle
20.56 0.00 20.31 0.10 0.10 58.93
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdb 0.00 5.80 0.00 102.50 0.00 6188.80 60.38 3.46 33.79 0.46 4.72
mongod考虑到所有这些，我假设瓶颈在于 CPU 使用率，对于进程来说，它始终稳定在 100% top（总计 200%，这意味着两个 CPU 中只有一个被使用）。58% 的空闲时间iostat也证实了这一点。
有什么方法可以确定 WiredTiger 存储是否按要求同时使用文档级锁定和两个 CPU 核心？或者这种情况是否可能由于 CPU 容量限制以外的其他原因而发生？
答案1
写入操作在单核实例上是串行执行的。读取操作具有并发性。这是我迄今为止从阅读中了解到的。
答案2
您有什么样的 mongodb 客户端设置以及什么样的硬件？
根据我在不同的系统上对不同的 mongodb 存储引擎进行基准测试的经验，单个 mongodb 实例的每秒操作数很快就会遇到瓶颈。
这可能是由于多种原因造成的，例如带宽瓶颈或调度时间。要确定是否是调度时间，您可以尝试并排运行 2 个 mongod 实例。如果它们都达到 2000 次更新/秒，并且每个实例使用 1 个 CPU，那么 mongod 调度更新命令所需的时间可能高于系统执行某些更新命令所需的时间。因此，mongod 没有理由使用另一个 CPU 核心，因为第一个核心始终为下一次更新做好准备（即使它处于极限）。
如果您仍然获得总共 2000 次更新/秒并且它们仍然只使用 1 个核心那么这将是一个不同的问题，我需要查看有关您的系统设置的更多信息才能猜测它是什么。
答案3
如果您想使用top，如果 mongoDB 是主要的 CPU 占用大户，您应该能够使用选项1（启动1后按下top）或使用此处描述的替代方法：如何测量某个进程的单独 CPU 核心使用情况？
对于 mongo 工具，这取决于版本（工具从 2.x 更改为 3.x，因此如何使用工具查看锁定信息将取决于您的版本），但db.serverStatus()应该会为您提供所需的信息。请参阅如何查看我的 mongod 实例上的锁状态？了解更详细的版本特定信息。请记住检查您使用的 MongoDB 版本是否与页面左上角的版本相匹配（单击版本号可更改您正在查看的文档的版本。）