-
Type:
Bug
-
Resolution: Duplicate
-
Priority:
Major - P3
-
None
-
Affects Version/s: 2.6.9
-
Component/s: Querying
-
None
-
ALL
I'm seeing something that looks like this with 2.6.9:
2015-04-20T16:26:05.147+0000 [conn61829] query *****.followings query: { $query: { user_id: ObjectId('*********') }, $orderby: { _id: 1 } } planSummary: IXSCAN { _id: 1 } ntoskip:0 nscanned:125454 nscannedObjects:125454 keyUpdates:0 numYields:0 locks(micros) r:181778 nreturned:0 reslen:20 181ms
db.followings.getIndexes()
[
{
"v" : 1,
"name" : "id",
"key" :
{ "_id" : 1 }
,
"ns" : "*****.followings"
},
{
"v" : 1,
"key" :
{ "user_id" : 1 }
,
"name" : "user_id_1",
"ns" : "***********.followings"
}
]
The query at the console on the primary always uses the 'user_id_1' index, but intermittently, the query will start running very slowly on slaves in the replica set. The behavior started after upgrading from 2.4 last week, and happens on some other simple collections too. If I drop and regenerate the index the problem resets itself, but I assume that's similar to just restarting mongod. What is normally a 1ms query jumps to 100ms or more.
- duplicates
-
SERVER-15225 CachedPlanStage should execute for trial period and re-plan if query performs poorly
-
- Closed
-