-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Build
-
Labels:None
-
ALL
Hello
We're facing similar issue and neither adding the index nor upgrading from 2.6.3 to 2.6.8 seem to fixed the problem. The error is of the following type:
2015-05-27T18:18:50.192-0500 [conn35] warning: ClientCursor::staticYield can't unlock b/c of recursive lock ns: top: { opid: 14571, active: true, secs_running: 0, microsecs_running: 823961, op: "query", ns: "henson_qa", query: { findandmodify: "expirationwork", query: { $and: [ { s: 0 }, { $or: [ { r.w: { $exists: false } }, { r.w: 58 } ] }, { r.b: { $ne: 58 } } ] }, sort: { p: 1 }, update: { $set: { s: 1, lut: 1432768729365 } }, new: true }, client: "10.x.x.x:58980", desc: "conn35", threadId: "0x7f4326c63700", connectionId: 35, locks: { ^: "w", ^henson_qa: "W" }, waitingForLock: false, numYields: 0, lockStats: { timeLockedMicros: {}, timeAcquiringMicros: { r: 0, w: 6 } } }
2015-05-27T18:18:50.193-0500 [conn35] warning: ClientCursor::staticYield can't unlock b/c of recursive lock ns: top: { opid: 14571, active: true, secs_running: 0, microsecs_running: 824538, op: "query", ns: "henson_qa", query: { findandmodify: "expirationwork", query: { $and: [ { s: 0 }, { $or: [ { r.w: { $exists: false } }, { r.w: 58 } ] }, { r.b: { $ne: 58 } } ] }, sort: { p: 1 }, update: { $set: { s: 1, lut: 1432768729365 } }, new: true }, client: "10.x.x.x:58980", desc: "conn35", threadId: "0x7f4326c63700", connectionId: 35, locks: { ^: "w", ^henson_qa: "W" }, waitingForLock: false, numYields: 0, lockStats: { timeLockedMicros: {}, timeAcquiringMicros: { r: 0, w: 6 } } }
Tried a bunch of combination of different indexes including the one you suggested. The actual index that the plan is honoring is only when there's a index on
{"r.w" : 1}. No hint is required for this. When added the index for
{s:1, r.w:1}and tried to impose it with the hint the query plan turned bad plus it never resolved the original problem
This is how the plan is for that query in the log now (which looks good but logging for those warnings hasn't stopped)
PRIMARY> db.expirationwork.find({ $and: [ { s: 0 }, { $or: [ { "r.w": { $exists: false } }, { "r.w": 60 } ] }, { "r.b": { $ne: 60 } } ] }).sort({ p : 1}).explain()
{
"cursor" : "BtreeCursor r.w_1",
"isMultiKey" : true,
"n" : 0,
"nscannedObjects" : 1,
"nscanned" : 2,
"nscannedObjectsAllPlans" : 1,
"nscannedAllPlans" : 2,
"scanAndOrder" : true,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 0,
"indexBounds" : {
"r.w" : [
[
null,
null
],
[
60,
60
]
]
},
"server" : "xxx-mongo6:27056",
"filterSet" : false
}
This is the plan when I tried to impose the composite index with the hint:
PRIMARY> db.expirationwork.find({ $and: [ { s: 0 }, { $or: [ { "r.w": { $exists: false } }, { "r.w": 60 } ] }, { "r.b": { $ne: 60 } } ] }).sort({ p : 1}).hint({"s" : 1,"r.w" : 1}).explain()
{
"cursor" : "BtreeCursor s_1_r.w_1",
"isMultiKey" : true,
"n" : 1,
"nscannedObjects" : 317212,
"nscanned" : 958844,
"nscannedObjectsAllPlans" : 317212,
"nscannedAllPlans" : 958844,
"scanAndOrder" : true,
"indexOnly" : false,
"nYields" : 7491,
"nChunkSkips" : 0,
"millis" : 23827,
"indexBounds" : {
"s" : [
[
0,
0
]
],
"r.w" : [
[
{
"$minElement" : 1
},
{
"$maxElement" : 1
}
]
]
},
"server" : "xxx-mongo6:27056",
"filterSet" : false
}
PRIMARY> db.version()
2.6.8
Note that at this point the MongoDB version has also been upgraded to 2.6.8 from the previous 2.6.3 when we first encountered this issue.
Should I create a separate JIRA ticket? Any suggestions would be greatly appreciated as the logs for this instance alone are filling up the disk space at roughly 5G / hour.
Attached is a sample of the log on the Primary server. Please suggest a fix.
Thank you.