Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-13943

Investigate changes in SERVER-40361: Reduce memory footprint of plan cache entries

    XMLWordPrintable

    Details

    • Last comment by Customer:
      true
    • Story Points:
      2
    • Sprint:
      ServerDocs2020: Mar9 - Mar16, ServerDocs2020: Mar16 - Mar23

      Description

      Description

      Downstream Change Summary

      There is a new setParameter 'internalQueryCacheMaxSizeBytesBeforeStripDebugInfo'. Its default value is 0.5 GB. The operator can increase the value of the parameter to allow more debug information to be stored in the plan cache, or reduce its value to save memory. By setting it to zero, no debug information will be stored alongside new plan cache entries.

      When the debug info for a plan cache entry has been stripped, $planCacheStats will return an entry that has the fields "queryHash", "planCacheKey", "isActive", "works", "timeOfCreation", "indexFilterSet", and "estimatedSizeBytes", but it will be missing the fields "createdFromQuery", "cachedPlan", "creationExecStats", and "candidatePlanScores". Note that "estimatedSizeBytes" is a new field which displays the estimated size in bytes of each plan cache entry.

      For documentation purposes, I'm not sure that we should document 'internalQueryCacheMaxSizeBytesBeforeStripDebugInfo', since hopefully the default will be appropriate for most applications. However, we should document the addition of the "estimatedSizeBytes" field to the $planCacheStats output.

      Description of Linked Ticket

      For some workloads, the per-collection query plan caches can consume too much memory. SERVER-34886 and SERVER-40360 together describe an architectural solution to this problem: turn the per-collection plan caches into a process-global plan cache, and bound the size of this new global cache in bytes rather than number of entries.

      However, we could also reduce the memory footprint of the plan cache by auditing the debug information it holds in memory. We have observed in the field that this problem is most severe when the user runs large queries; this can result in the information held in the plan cache for introspection taking up a lot of memory. Perhaps this debug information can be truncated if it exceeds some threshold, in order to reduce the amount of debug information present in exchange for avoidance of excessive memory consumption.

      The suspected worst offenders are:

      Scope of changes

      Impact to Other Docs

      MVP (Work and Date)

      Resources (Scope or Design Docs, Invision, etc.)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              naomi.pentrel Naomi Pentrel
              Reporter:
              backlog-server-pm Backlog - Core Eng Program Management Team
              Participants:
              Last commenter:
              Naomi Pentrel Naomi Pentrel
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Days since reply:
                24 weeks ago
                Date of 1st Reply: