During my aggregation tests I found that mongo sometimes uses 100% in one
core and sometimes not and as a consequence, the time of response varies a
This CPU usage can also vary from an aggregation query to another (for
example : if a want to aggregate more documents).
Although in most cases MongoDB is not CPU-bound, some processing in MongoDB
is relatively CPU-intensive, for example:
Although the $match stage can use an index, once the pipeline enters the
$group (or $project) stage, no index can be used. The reason for this is an
index is closely tied to how the documents are stored in disk. Indexes can
help to speed up find() queries (since find() does not reshape documents),
but $group and $project stage reshape the documents in-memory so any
indexes no longer applies. In other words, $group stage will output
documents that do not have a physical representation in disk, and thus
indexes (which are tied to the physical location of a document) cannot be
If your $match stage is not selective enough (e.g. it returns a lot of
documents), then the $group stage will have to calculate average values of
a large numbers of documents. If the documents involved need to be fetched
and uncompressed from disk, it will also add up to the CPU usage you are
I would suggest using mongotop, mongostat, and other performance
measurement tools to determine what happened during the aggregation query
in your deployment.
You received this message because you are subscribed to the Google Groups "mongodb-user"