-
Type: Task
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
None
-
Sharding EMEA 2021-11-01, Sharding EMEA 2021-11-15
The goal of this task is to evaluate the performance impact of acquiring the critical section on the recipient as part of the new migration protocol.
More specifically, we would like to know:
- How long are we holding the CS on the donor and recipient compared to the previous implementation.
- Impact of the optimization proposed by Andy on the technical design document (i.e. skipping one hop).
- Are we overlapping the execution of the refresh of the filtering information on the donor with the one on the recipient?
The proposed workload is to create a sharded collection with N chunks: N-1 chunks will be empty except one that will have some data (Q: should it be an input of the workload? IMO it could be interesting but not at the beginning). Once everything is properly set up, the workload should move this chunk from the donor shard to another shard and get some metrics. We will repeat this process M times.
Some considerations:
- The baseline of the comparison should be master without our changes (i.e. we are going to compare the old migration protocol against the new one). We can take 5.2 without the feature flag, so we don't have any problem with the recent changes we did on the chunksize.
- depends on
-
SERVER-60984 Report time in recipient critical section on serverStatus' shardingStatistics
- Closed
- related to
-
SERVER-58991 Acquire the critical section on the recipient shard of a moveChunk operation
- Closed