-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Query Optimization
When we built the SBE plan cache, we designed it as a singleton object decorating the ServiceContext. This meant that it needed to be partitioned to avoid contention of mutexes, in much the same way that we partition the CursorManager.
The classic plan cache, in contrast, has a separate cache per-collection, each with its own mutex. Therefore, contention is reduced if the workload runs across many collections. However, there is just a single partition per collection – although the classic plan cache shares the partitioning code with the SBE plan cache, we use the default value of 1 partition when constructing the classic PlanCache object.
If the workload involves enough concurrency against a single collection, then we could still see contention on the classic PlanCache mutex. We should consider partitioning the classic plan cache to improve performance in such cases. Also see related ticket SERVER-49275 which suggests using a reader/writer lock.
- related to
-
SERVER-90883 TSAN deadlock detection fails on large hosts due to lock-per-core in SBE plan cache
- Closed
-
SERVER-49275 Improve performance of plan cache under heavy read workloads
- Backlog