[SERVER-70926] Low priority operations aren't able to modify priority at runtime Created: 28/Oct/22 Updated: 11/Nov/22 Resolved: 11/Nov/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Jordi Olivares Provencio |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Execution Team 2022-11-14 |
| Participants: |
| Description |
|
Suppose deletes on a specific TTL collection are not able to keep up with the number of writes. There have been several cases where the collection growth becomes an issue. We should enable low priority operations to dynamically switch and bump their priority given the state of the server / its operation. |
| Comments |
| Comment by Jordi Olivares Provencio [ 11/Nov/22 ] |
|
Long term we want to have a more intelligent approach to scheduling by each component exposing how much work left it has and reprioritize based on that. As this is only a short term fix we will not continue on this approach as it will immediately become tech debt. |
| Comment by Haley Connelly [ 10/Nov/22 ] |
|
After speaking with the design crew, we've decided this is not a path we want to pursue. We don't want to require users to pass a function or callback on a hot code path for lock acquisition. Additionally, we are moving toward a future where it is up to the scheduler to decide what to do with an operation given some input, rather than the operation define itself how to be handled. |