[SERVER-18740] warning: ClientCursor::staticYield can't unlock b/c of recursive lock Created: 29/May/15 Updated: 18/Jun/15 Resolved: 18/Jun/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Manan Shah | Assignee: | Ramon Fernandez Marina |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Operating System: | ALL |
| Participants: |
| Description |
|
Hello
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 the plan when I tried to impose the composite index with the hint:
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. Attached is a sample of the log on the Primary server. Please suggest a fix. |
| Comments |
| Comment by Manan Shah [ 18/Jun/15 ] |
|
Hi Ramon, |
| Comment by Ramon Fernandez Marina [ 18/Jun/15 ] |
|
manan@indeed.com, apologies for the long delay. 3.0 eliminates this problem, as findAndModify() queries can now yield, so you may want to consider upgrading to 3.0.4 (the latest release at the moment). I understand changing the storage engine is a big commitment, so you can upgrade to v3.0 with MMAPv1 now, and later evaluate the move to WT. As far as I can tell, if your queries are already using the best index then the warnings in the log are unavoidable. The good news is that If neither upgrading nor waiting for 2.6.11 are an option, you can consider more frequent log rotation or logging to syslog and use filters to drop these messages. I'm going to close this ticket now. I'd invite you to consider testing 3.0.4 with MMAPv1 and upgrade if it meets your needs. Regards, |
| Comment by Manan Shah [ 29/May/15 ] |
|
Hi Ramon . Note that we added this index on production only yesterday and we're going to keep it as it seems to be helping the findAndModify query. As you can see in the second plan output that forcing a different index only worsened the plan and I don't see any reason to use that other composite index. Now the only other alternative I could think of is to eliminate findAndModify and write the query differently if that helps with the logging of warnings. Down the line we shall upgrade this to MongoDB 3.0 WT engine but this may take some time (Not sure though if 3.0 would address this issue at all). |
| Comment by Ramon Fernandez Marina [ 29/May/15 ] |
|
Thanks for opening a separate ticket manan@indeed.com . As mentioned in |