[SERVER-45703] Make CollectionShardingStateMap copy-on-write/otherwise lock-free Created: 22/Jan/20 Updated: 06/Dec/22 Resolved: 14/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matthew Saltz (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Operating System: | ALL |
| Participants: |
| Description |
|
The CollectionShardingState must be accessed on nearly every operation in a sharded cluster, which leads to a lot of contention on this mutex, as seen in a local perf run (though of course that's not a perfect representation). Because currently we never delete items from the map (it's append-only), and we only rarely add new items (on sharded collection creation), I think it would be a good candidate for a lock-free copy-on-write data structure, which would allow reads which do not create new entries to occur with only a few atomic reads rather than a full mutex acquisition. It would be pretty easy to try this and perf test it. At the very least, we could change the mutex to a ResourceMutex so that reads only require a SharedLock rather than an exclusive lock. |
| Comments |
| Comment by Esha Maharishi (Inactive) [ 14/Feb/20 ] |
|
Closing the ticket but linked on the sharding pain points doc to track the context in this ticket. |