Re: Variation in CPU usage and time response in aggregation framework

From: Kevin Adistambha <kevinadi@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Wed, 20 Apr 2016 16:00:25 -0700 (PDT)
Why ads?


Hi,

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 
lot.
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:

   - By default, MongoDB 3.2 uses snappy compression 
   <https://docs.mongodb.org/manual/core/wiredtiger/#compression> to 
   compress data. Compression and decompression of data lead to higher CPU 
   usage but potentially significant reductions in storage and I/O. 
   - The WiredTiger storage engine is multithreaded 
   <https://docs.mongodb.org/manual/administration/production-notes/#id3
   and will take advantage of any additional CPU cores to increase throughput. 
   - Some aggregation pipeline that involves calculation will increase CPU 
   usage. 

There are some performance profiling tools that may be of help to you:

   - mongostat 
   <https://docs.mongodb.org/manual/reference/program/mongostat/> provides 
   the status of a currently running mongod or mongos process. 
   - mongotop <https://docs.mongodb.org/manual/reference/program/mongotop/
   provides information about the time it took for MongoDB to read and write 
   data. 
   - db.currentOp() 
   <https://docs.mongodb.org/manual/reference/method/db.currentOp/#db.currentOp
   command shows what operation is currently running. 

Also, there are some pages that may be of help:

   - Analyzing MongoDB Performance 
   <https://docs.mongodb.org/manual/administration/analyzing-mongodb-performance/
   - Evaluate Performance of Current Operations 
   <https://docs.mongodb.org/manual/tutorial/evaluate-operation-performance/
   - Aggregation Pipeline Optimization 
   <https://docs.mongodb.org/manual/core/aggregation-pipeline-optimization/
   - Production Notes 
   <https://docs.mongodb.org/manual/administration/production-notes/
   - An upcoming optimization in the $group stage: SERVER-4507 
   <https://jira.mongodb.org/browse/SERVER-4507

However, I can give you some pointer regarding your aggregation query:

db.consumption.aggregate([
{$match:  {ID_1:{$lte:500},Time:{$lte :1461908939}}},
{$group:{
    _id:{"ID_1":"$ID_1","ID_2":"$ID_2"},
    AvgValue:{$avg:"$Value"}
}}])

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 
used anymore.

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 
seeing.

I would suggest using mongotop, mongostat, and other performance 
measurement tools to determine what happened during the aggregation query 
in your deployment.

Best regards,
Kevin


-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.org/manual/support/
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/0009da99-efed-4f38-92d4-3e7484ab495d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?