如WiredTiger存储引擎描述中所述，由于文档级locking，它提供了更好的并发能力。 从这个职位 ：
WiredTiger采用现代化的多CPU架构进行扩展。 使用各种编程技术，如危险指针，无锁algorithm，快速锁存和消息传递，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/sr/sw/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
考虑到所有这一切，我认为瓶颈在于CPU使用率，对于mongod进程，总是始终稳定在100％（总共200％，这意味着只有一个CPU使用两个CPU） 。 58％的闲置时间从iostat也证实了这一点。
有什么方法可以确定WiredTiger存储器是否同时使用文档级locking和两个CPU内核？ 或者由于除CPU容量限制以外的任何原因，这可能发生？
写操作正在单核实例上串行完成。 阅读操作具有一致性。 这是我迄今从我的阅读中理解的。
你有什么样的mongodb客户端设置和什么样的硬件？
根据我的经验，在不同的系统上对不同的mongodb存储引擎进行基准testing，一个单一的mongodb实例可以很快地在每秒操作上遇到困难。
这可能是由于各种原因，如带宽瓶颈或调度时间。 要确定是否有调度时间，可以尝试并排运行2个mongod实例。 如果两者达到2000次更新/秒并且每次使用1个CPU，那么mongod分派更新命令花费的时间可能比系统执行某些更新命令所用的时间要长。 因此，mongod没有理由使用其他的cpu核心，因为第一个是随时可用于下一次更新（即使是在极限）。
如果你仍然得到2000次更新/秒的总数，而且它们之间仍然只使用1个内核，那么这将是一个不同的问题，我需要查看更多关于系统设置的信息来猜测它是什么。
如果你想使用top ，如果mongoDB是主CPU，你应该不能使用1选项，（在top启动之后按1 ），或者使用如下所述的替代方法： 如何测量单独的CPU核心使用率处理？
对于mongo工具，这是依赖于版本的（工具从2.x更改为3.x，所以如何使用工具来查看locking信息将取决于您的版本），但db.serverStatus()应该为您提供信息寻找。 请参阅如何查看mongod实例上锁的状态？ 有关更详细的版本特定信息。 请记住检查您使用的MongoDB版本是否与页面左上angular的版本匹配（单击版本号以更改您正在查看的文档版本）。