[SERVER-66149] Investigate write stalls in mixed_workloads with dynamic concurrency Created: 03/May/22 Updated: 12/May/22 Resolved: 12/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Daniel Gomez Ferro | Assignee: | Daniel Gomez Ferro |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Sprint: | Execution Team 2022-05-16 | ||||
| Participants: | |||||
| Description |
|
When running with few read/write tickets, the mixed_workloads_genny test has episodes where writes are stopped and only reads get through:
|
| Comments |
| Comment by Daniel Gomez Ferro [ 12/May/22 ] |
|
In this workload, after a long running checkpoint we accumulate lots of updates in the `config.transactions` collection (each write updates its session document). When the checkpoint transaction finishes all those updates become obsolete and WT decides to evict the page to trim the long update chain. This will happen for most pages in the collection, so write throughput gets severely affected during this time. If we had more write tickets the effect might not be as noticeable because we'd evict much more pages in parallel. The cause for the long running checkpoint could be high CPU utilization. |