Mongodb Mongo';s aggregate命令未充分利用CPU

Mongodb Mongo';s aggregate命令未充分利用CPU,mongodb,performance,aggregation-framework,Mongodb,Performance,Aggregation Framework,我让Mongo2.2.2在Windows7x64上运行,在i7八核CPU上运行。我们的生产服务器在Red Hat Enterprise下运行,在256台核心机器上运行相同版本的Mongo 在我的Windows计算机上的以下调用的测试中 db.users_v2_prod.aggregate( { $group : {_id : "$email", total : { $sum : 1 } } }, { $match : { total : { $gte : 3 } } }, { $sort : {

我让Mongo2.2.2在Windows7x64上运行,在i7八核CPU上运行。我们的生产服务器在Red Hat Enterprise下运行,在256台核心机器上运行相同版本的Mongo

在我的Windows计算机上的以下调用的测试中

db.users_v2_prod.aggregate( { $group : {_id : "$email", total : { $sum : 1 } } }, { $match : { total : { $gte : 3 } } }, { $sort : {total : -1} }, {$limit : 5} )
我注意到mongo未充分利用可用资源。在查询期间,CPU上的总负载约为10%。根据Process Explorer,计算只发生在一个线程中
mongod
似乎只使用了我拥有的8个内核中的3个,甚至部分使用了它们

能否请Mongo的工程师解释一下他们实施该方案的理由?我很好奇,如果资源可用,为什么不使用更多的资源呢。既然有我分组的字段的索引,为什么不在所有核心上并行加载呢

给定的查询是对包含650万个文档的集合执行的(mongobackup生成5GB文件)。所以这没什么疯狂的


附言和奖金问题:你想过使用GPU吗?我的笔记本电脑上有1024个内核的GPU:)

很有可能,CPU不是这里的边界因素-对于MongoDB的典型用例,大多数情况下都是这样。您的查询看起来并不是计算密集型的,所以它更有可能在磁盘分页数据或内存不足方面达到极限

很难说没有看到运行的实际统计数据(因此我建议安装主机),但我很少看到CPU成为MongoDB实例的瓶颈

尽管如此,并行化可能会得到改进,但它可能不是实现的最快的方法。如果上述任何一项都不相关,那么我会看看您是否可以并行运行多个作业,或者在客户端将工作进行更多的拆分,看看您是否可以通过这种方式改进问题。您可能还应该关注/投票/评论这些问题:

(并行化聚合操作) (并行查询)
(添加聚合框架的解释)(在2.6中添加)

为什么您认为这是CPU受限的?MapReduce和其他简单的JavaScript工具,如
eval()
,仅限于一个内核,但其他一切都不应限于此。也许更多的细节(
iostat
vmstat
,…)有助于更好地了解情况。不幸的是,目前还没有用于聚合查询的
explain()
,但是您的应该很好-看,我不是MongoDB开发人员,但是多线程聚合在JIRA上的某个地方,我相信,我找不到它,因为我在搜索它时很差劲。因此,肯定有计划在未来通过处理多线程之类的东西使管道变得更好。