Currently, only one moveChunk operation can occur between two shards at a time. It has been observed that tests, such as sharded_moveChunk_partitioned.js, random_moveChunk_timeseries_inserts.js utilize 5 threads to perform concurrent moveChunk operations on a two-shard cluster in most concurrency suites. This setup appears excessive and introduces unnecessary contention, which has previously caused issues such as redundancy and timeouts, particularly in slower variants with sluggish progress.

The purpose of this ticket is to review these concurrency tests and adjust parameters such as the number of threads, the number of shards (from the suite yaml), the frequency of moveChunk operations, etc. to sufficient and reasonable values.