[SERVER-61196] Investigate simplifications to BucketCatalog concurrency model Created: 02/Nov/21 Updated: 21/Jan/22 Resolved: 21/Jan/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dan Larkin-York | Assignee: | Dan Larkin-York |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Execution Team 2021-12-13, Execution Team 2021-12-27, Execution Team 2022-01-10, Execution Team 2022-01-24 |
| Participants: |
| Description |
|
The fine-grained locking hierarchy currently used in the BucketCatalog is difficult to reason about and has led to several bugs. We are hoping to simplify this without sacrificing too many of the performance gains we achieved by implementing the fine-grained locking in the first place. We can consider any simplifications, but one might be worth checking first: shard the catalog by bucket metadata. Each shard can be protected by a simple mutex. Much of the work on the insert path could be done outside these mutexes, and operations on unrelated buckets would be unlikely to block each other. |
| Comments |
| Comment by Githook User [ 21/Jan/22 ] |
|
Author: {'name': 'Dan Larkin-York', 'email': 'dan.larkin-york@mongodb.com', 'username': 'dhly-etc'}Message: |