I have a collection of 10M documents, that is a pre-aggregation of daily events.
A simple $group took more than 8s, is this performance normal ?
Some date from the profiler :
{
"op" : "command",
"ns" : "analytics.$cmd",
"command" : {
"aggregate" : "aggregation",
"pipeline" : [
{
"$group" : {
"_id" : "",
"hits" : {
"$sum" : "$hits"
}
}
}
]
},
"ntoreturn" : 1,
"keyUpdates" : 0,
"numYield" : 15,
"lockStats" : {
"timeLockedMicros" : {
"r" : NumberLong(17169805),
"w" : NumberLong(0)
},
"timeAcquiringMicros" : {
"r" : NumberLong(8582619),
"w" : NumberLong(294)
}
},
"responseLength" : 78,
"millis" : 8594,
"ts" : ISODate("2013-12-04T15:57:38.217Z"),
"client" : "127.0.0.1",
"allUsers" : [ ],
"user" : ""
}
Here is one single document
{
"_id" : ObjectId("529e21ee67e807418500daeb"),
"date" : ISODate("2012-09-19T00:00:00Z"),
"hits" : 1,
"infos" : {
"sourceValue" : NumberLong(1),
"eventType" : "createUser",
"sourceType" : "user",
"instance" : "xxx",
"targetType" : "user",
"targetValue" : NumberLong(15)
}
}
Related
I have a Pageable request which query for about 1.6 millions documents and each request limit the response to 1000 documents. The query use an index... Well at least it should... I'm using db.currentOp() to look for the request that takes a while to process. When I launched the query (yesterday at 01:00PM) it used the index for each portion of 1000. But it seems that at some point he decided not to use it anymore... And I can't figure out why...
I also have a command operation for the same query and it is using the index.
{
"desc" : "conn7758",
"threadId" : "1012",
"connectionId" : 7758,
"client" : "10.10.10.3:64670",
"clientMetadata" : {
"driver" : {
"name" : "mongo-java-driver",
"version" : "unknown"
},
"os" : {
"type" : "Windows",
"name" : "Windows Server 2008 R2",
"architecture" : "x86",
"version" : "6.1"
},
"platform" : "Java/Oracle Corporation/1.8.0_73-b02"
},
"active" : true,
"opid" : 119588895,
"secs_running" : 1299,
"microsecs_running" : NumberLong(1299666014),
"op" : "command",
"ns" : "thingsplay.data",
"query" : {
"count" : "data",
"query" : {
"device" : "S000110",
"topic" : "INPUTS/COIL1000",
"date" : {
"$gt" : ISODate("2015-08-08T06:00:00Z"),
"$lt" : ISODate("2018-06-14T11:28:08.369Z")
}
}
},
"planSummary" : "IXSCAN { device: 1, topic: 1, vhost: 1}",
"numYields" : 81449,
"locks" : {
"Global" : "r",
"Database" : "r",
"Collection" : "r"
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(162900)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(81450)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(81450)
}
}
}
}
The request is still running... and I think it will be for a couple of hours.
Here is the last operations that is running :
{
"desc" : "conn7758",
"threadId" : "1012",
"connectionId" : 7758,
"client" : "10.10.10.3:64670",
"clientMetadata" : {
"driver" : {
"name" : "mongo-java-driver",
"version" : "unknown"
},
"os" : {
"type" : "Windows",
"name" : "Windows Server 2008 R2",
"architecture" : "x86",
"version" : "6.1"
},
"platform" : "Java/Oracle Corporation/1.8.0_73-b02"
},
"active" : true,
"opid" : 120813021,
"secs_running" : 134,
"microsecs_running" : NumberLong(134586683),
"op" : "query",
"ns" : "thingsplay.data",
"query" : {
"find" : "data",
"filter" : {
"device" : "S000110",
"topic" : "INPUTS/COIL1000",
"date" : {
"$gt" : ISODate("2015-08-08T06:00:00Z"),
"$lt" : ISODate("2018-06-14T11:28:08.369Z")
}
},
"projection" : {
},
"skip" : 1124000,
"limit" : 1000
},
"numYields" : 8445,
"locks" : {
"Global" : "r",
"Database" : "r",
"Collection" : "r"
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(16892)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(8446)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(8446)
}
}
}
}
Unfortunately I don't have the operation of the first operations that went well but you can see here that it doesn't use the index.
[
{
"v" : 2,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "thingsplay.data"
},
{
"v" : 2,
"key" : {
"device" : 1,
"topic" : 1,
"date" : 1
},
"name" : "device_1_topic_1_date_1",
"ns" : "thingsplay.data",
"background" : true
},
{
"v" : 2,
"key" : {
"device" : 1,
"topic" : 1,
"vhost" : 1
},
"name" : "device_1_topic_1_vhost_1",
"ns" : "thingsplay.data",
"background" : true
}
]
I'm using MongoDB to store data with the following structure :
{ "_id" : ObjectId("5a497a1f451bf00880331913"), "device" : "deviceId", "topic" : "topicId", "vhost" : "vhostId", "date" : ISODate("2018-01-01T00:00:31.220Z"), "value" : 452 }
with the following indexes :
[
{
"v" : 2,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "thingsplay.data"
},
{
"v" : 2,
"key" : {
"device" : 1,
"topic" : 1,
"date" : 1
},
"name" : "device_1_topic_1_date_1",
"ns" : "thingsplay.data",
"background" : true
},
{
"v" : 2,
"key" : {
"device" : 1,
"topic" : 1,
"vhost" : 1
},
"name" : "device_1_topic_1_vhost_1",
"ns" : "thingsplay.data",
"background" : true
}
]
But when I'm making a query with device, topic and date fields it uses device_1_topic_1_vhost_1 index...
For another request with the explain option I just had the right winning plan (device_1_topic_1_date_1) but when I execute it... I'm still waiting for it to complete and with db.currentOp() I don't see it using any index...
{
"desc" : "conn2172",
"threadId" : "2836",
"connectionId" : 2172,
"client" : "x.x.x.x:50177",
"appName" : "MongoDB Shell",
"clientMetadata" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
"name" : "MongoDB Internal Client",
"version" : "3.6.2"
},
"os" : {
"type" : "Windows",
"name" : "Microsoft Windows Server 2008 R2",
"architecture" : "x86_64",
"version" : "6.1 SP1 (build 7601)"
}
},
"active" : true,
"opid" : 22137990,
"secs_running" : 322,
"microsecs_running" : NumberLong(322246758),
"op" : "command",
"ns" : "company.data",
"query" : {
"explain" : {
"find" : "data",
"filter" : {
"device" : "deviceId",
"topic" : "topicId",
"date" : {
"$gt" : ISODate("2018-01-01T00:00:00Z"),
"$lt" : ISODate("2018-06-12T16:18:00Z")
}
}
},
"verbosity" : "executionStats"
},
"numYields" : 19245,
"locks" : {
"Global" : "r",
"Database" : "r",
"Collection" : "r"
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(38492)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(19246)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(19246)
}
}
}
}
I don't understand why the index is not being used...
We are running MongoDB 3.0.2 on Linux.
The "getmore" operation for a find query periodically hangs.
The operation is available currentOp(), and one item I cannot explain is that all the acquireCount values in lockStats continue to grow while the query hangs (for Global, MMAPV1Journal, Database, and Collection).
This is the operation in question, at this point running for more than 1000 secs, returned by db.currentOp() :
{
"desc" : "conn60",
"threadId" : "0x2a99ee0",
"connectionId" : 60,
"opid" : 67792,
"active" : true,
"secs_running" : 1098,
"microsecs_running" : NumberLong(1098289543),
"op" : "getmore",
"ns" : "dbName.collectionName",
"query" : {
"d" : {
"$gt" : ISODate("2016-03-13T18:00:00.261Z"),
"$lt" : ISODate("2016-03-14T22:45:17.718Z")
},
"cc" : "US",
"dc" : {
"$in" : [
"26",
"31",
"17",
"29",
"35"
]
},
"pr" : {
"$gte" : 4
}
},
"client" : "10.0.0.111:33670",
"numYields" : 317557,
"locks" : {
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(635114)
}
},
"MMAPV1Journal" : {
"acquireCount" : {
"r" : NumberLong(317557)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(317557)
}
},
"Collection" : {
"acquireCount" : {
"R" : NumberLong(317557)
}
}
}
}
Any insights would be much appreciated ! Thank you in advance.
We see a lot of slow queries in mongo logs like below (with pipeline op mergeCursors). We have a shaded mongo with 2 shards with only primaries. What is mergeCursors command? Please let me know if any other information is required.
{
"_id" : ObjectId("5571b739f65f7e64bb806362"),
"op" : "command",
"ns" : "mongrel.$cmd",
"command" : {
"aggregate" : "collection1",
"pipeline" : [
{
"$mergeCursors" : [
{
"host" : "endpoint:27005",
"id" : NumberLong(82775337156)
}
]
}
]
},
"keyUpdates" : 0,
"numYield" : 0,
"lockStats" : {
"timeLockedMicros" : {
"r" : NumberLong(12),
"w" : NumberLong(0)
},
"timeAcquiringMicros" : {
"r" : NumberLong(2),
"w" : NumberLong(2680)
}
},
"responseLength" : 12312,
"millis" : 6142,
"execStats" : {},
"ts" : ISODate("2015-06-05T12:35:40.801Z"),
"client" : "10.167.212.83",
"allUsers" : [],
"user" : ""
}
I was recently reading this post (http://dbattish.tumblr.com/post/108652372056/joins-in-mongodb) which seems to say that it is an internal aggregate command to merge queries across shards.
I am trying to profile the performance of an aggregation pipeline, specifically checking whether indices are used, how many objects are scanned, etc.
I'm setting the DB to full profiling:
db.setProfilingLevel(2)
But then in the db's 'system.profile' collection, in the result record for the aggregation command, the execStats is always empty.
Here is the full result for the command:
{
"op" : "command",
"ns" : "mydb.$cmd",
"command" : {
"aggregate" : "mycolection",
"pipeline" : [{
"$match" : {
"date" : {
"$gte" : "2013-11-26"
}
}
}, {
"$sort" : {
"user_id" : 1
}
}, {
"$project" : {
"user_id" : 1,
"_id" : 0
}
}, {
"$group" : {
"_id" : "$user_id",
"agg_val" : {
"$sum" : 1
}
}
}],
"allowDiskUse" : true
},
"keyUpdates" : 0,
"numYield" : 16,
"lockStats" : {
"timeLockedMicros" : {
"r" : NumberLong(3143653),
"w" : NumberLong(0)
},
"timeAcquiringMicros" : {
"r" : NumberLong(140),
"w" : NumberLong(3)
}
},
"responseLength" : 4990,
"millis" : 3237,
"execStats" : { },
"ts" : ISODate("2014-11-26T16:20:59.576Z"),
"client" : "127.0.0.1",
"allUsers" : [],
"user" : ""
}
Support execStats for aggregation command was added in mongo 3.4.