[SERVER-8654] yielding too much? Created: 21/Feb/13 Updated: 05/Apr/17 Resolved: 05/Dec/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | 2.4.0-rc0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Dwight Merriman | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
It appears that we are yielding quite a bit in receivedQuery and receivedGetMore when a secondary is pulling from the oplog. In the scenario shown below the secondary was catching up. The output below is from when it was scanning before reaching a { ts : { $gte : ... }} point; after that it is yielding except maybe every 3ms instead of every 1ms. This test was done on windows. An extra 1K local db lock acquisitions per second can't be helpful...
More info:
initial scan: queryWithQueryOptimizer() 100% getmore: receivedGetMore() 97% |
| Comments |
| Comment by Geert Bosch [ 07/Dec/16 ] |
|
The query knobs are available regardless of storage engine, and they can be changed at run time. When there are workloads where we observe that changing the values significantly improves performance we could consider changing the defaults. |
| Comment by Dwight Merriman [ 06/Dec/16 ] |
|
fwiw the original context of the jira is mmap. Perhaps it is not an issue, but if tickets come up where a primary is slow when a secondary is catching up, and mmap is in play, I would consider this. |
| Comment by Geert Bosch [ 05/Dec/16 ] |
|
We have setParameter knobs internalQueryExecYieldIterations and internalQueryExecYieldPeriodMS that allow changing yielding behavior. In our experience the current default values are appropriate, as increasing them does not give meaningful performance increases. Values that are too high increase latency of operations that need to acquire database resources in exclusive or shared locking modes as opposed to intent modes. With document locking storage engines, such as WiredTiger most operations only take intent locks, which only touch thread-local memory. and have relatively low overhead, so the cost of yielding isn't that high. |