-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.0.8, 3.3.11
-
Component/s: Sharding
-
None
-
ALL
-
-
Sharding 2016-09-19, Sharding 2016-10-10, Sharding 2016-10-31
I've been testing the speed of chunk migrations in an all-on-one-server test cluster. Even when the chunks being migrated are empty (i.e. the chunk move takes only ~0.1 secs) the entire cycle run by the balancer takes a lot longer.
version | balance round time |
---|---|
3.0.8 | ~4.5 secs |
v3.3.11-30-gc96009e | ~ 9 secs |
From someone's else case with v3.2 and different servers / network to my test I heard of a ~6 second cycle. Not sure if that was a replica set config db or the older SCCC-style one.
Can the balancer be changed so that the balance round will do multiple chunks of each collection so long as they finish quickly? E.g. balance round identifies candidate chunks for migrations, and keeps on doing chunk moves for them serially until a, say, 10 sec window completes.
At any rate if data has been completely deleted for a big fraction of chunk ranges before adding a new shard, it would be good if those chunks moves happened a lot more quickly.
- is related to
-
SERVER-26770 Sharding balancer moves chunks from shards whose utilization is below the cluster average
- Closed
-
SERVER-26791 move/split/mergeChunk commands do a full metadata refresh on the shard
- Closed
-
SERVER-26778 Improve the speed of incremental chunk metadata refresh
- Closed
-
SERVER-26684 Chunk diffing code roundtrips between ChunkType and BSON during reload
- Closed
-
SERVER-26777 Improve logging around chunk metadata refresh
- Closed