I am trying to debug a high CPU issue on MongoDB instance. We have two shard r3.large AWS instances. There are not many page faults compared to ops count.
System profile shows ton of getmore entries like below. Please help me in finding out what causing the getmore to be very slow.
{
"op" : "getmore",
"ns" : "mydb.mycollection",
"cursorid" : 74493486271,
"ntoreturn" : 0,
"keyUpdates" : 0,
"numYield" : 7,
"lockStats" : {
"timeLockedMicros" : {
"r" : NumberLong(16140),
"w" : NumberLong(0)
},
"timeAcquiringMicros" : {
"r" : NumberLong(6458801),
"w" : NumberLong(294321)
}
},
"nreturned" : 120,
"responseLength" : 13100,
"millis" : 6304,
"execStats" : {
},
"ts" : ISODate("2015-06-16T14:20:39.886Z"),
"client" : "1.5.1.3",
"allUsers" : [ ],
"user" : ""
}
If you've tried all the internal optimizations you can think of within MongoDB and your queries are still too slow, it may be time for an external index. Using an external index, your data can be indexes and queried from an entirely separate database with a completely different set of strengths and limitations.
Definition. getMore. Use in conjunction with commands that return a cursor, e.g. find and aggregate , to return subsequent batches of documents currently pointed to by the cursor.
The default internal sort order (or natural order) is an undefined implementation detail.
Answering my own question it may help some one else.
db.adminCommand( { setParameter: 1, logLevel: 1 } )
, after did reset to logLevel: 0 (default).Aggregate query has cursor: { batchSize: 0 }
with initial batch size as zero. So, the query returns quickly. But when application started iterating thru cursor, then the getmore is logged and that entry doesn't have any query details.
Fixing aggregating query $match to use indexes solved problem
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With