Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-90940

Partition the Classic plan cache to reduce lock contention

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 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.

            Assignee:
            steve.tarzia@mongodb.com Steve Tarzia
            Reporter:
            jess.balint@mongodb.com Jess Balint
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: