[SERVER-20763] Performance regression in find command (versus legacy OP_QUERY) due to additional contended calls into CursorManager Created: 05/Oct/15 Updated: 15/Oct/15 Resolved: 09/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.2.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Martin Bligh | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
Run this script:
You get much more lock contention with the command path vs not: benchRun.find 32 false 30
vs:
Contention appears to be CursorManager::_mutex. |
| Comments |
| Comment by David Storch [ 09/Oct/15 ] | ||||||||||||||||||||||||||||
|
The change for this ticket resolves contention on the CursorManager mutex for a query workload that does not require any getMores. Further performance work for the new find and getMore commands path will be done under | ||||||||||||||||||||||||||||
| Comment by Githook User [ 09/Oct/15 ] | ||||||||||||||||||||||||||||
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: Find command point queries now acquire the CursorManager mutex just | ||||||||||||||||||||||||||||
| Comment by Martin Bligh [ 07/Oct/15 ] | ||||||||||||||||||||||||||||
|
Patch fixes about half the perf delta. Profile is now
| ||||||||||||||||||||||||||||
| Comment by David Storch [ 07/Oct/15 ] | ||||||||||||||||||||||||||||
|
I hacked the find command path to not require the extra acquisitions of the CursorManager mutex. (I gave the find command's PlanExecutor a manual yield policy so that it gets registered with the CursorManager just once, when we pass ownership of the PlanExecutor to the ClientCursor.) On my machine, this showed about a 1% improvement in throughput for the find-by-_id benchRun workload. This leads me to believe that contention on CursorManager::_mutex is not the main problem. CC martin.bligh UPDATE: Martin can still reproduce this on his more powerful machine, and proved that my PlanExecutor manual yield policy hack significantly alleviates the problem. Plan is now to move forward with finding a fix. |