-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
ClusterScalability 26Oct-9Nov
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Concurrent reshardings on distinct namespaces (seeĀ SERVER-136621) currently share a single PrimaryOnlyService thread pool per service. The coordinator admission cap max(1, (reshardingCoordinatorServiceMaxThreadCount - 1) / 3) exists only to keep concurrent operations from starving each other on that shared pool. Give each resharding operation its own thread pool, so concurrency scales until machine resources are the limit. the follow up work will remove the cap's dependency on MaxThreadCount and revert the MaxThreadCount server parameter values to their original defaults (SERVER-138643), but this ticket should not do that.
- is related to
-
SERVER-138643 Remove resharding op cap dependency on thread pool max counts and reset thread pool to original defaults
-
- Closed
-
- related to
-
SERVER-138298 Pull out max reshardings cap into a cluster parameter and restore default max thread counts
-
- In Progress
-
-
SERVER-136621 Remove explicit gate on concurrent reshardings in coordinator service to allow a capped number of concurrent reshardings
-
- Closed
-