Details
-
Task
-
Resolution: Done
-
Major - P3
-
None
-
None
Description
Description
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:
- A serialized representation of the index bounds for an IXSCAN stage. We've seen this for queries with $in predicates that have hundreds of thousands of elements. If the $in is converted into index bounds, the serialized bounds will consist of hundreds of thousands of point intervals.
- A copy of the query predicate. This can approach 16MB on its own per plan entry if the user runs large queries.
- Another copy of the a potentially large predicate, held inside the stats for a FETCH stage.
Scope of changes
Impact to Other Docs
MVP (Work and Date)
Resources (Scope or Design Docs, Invision, etc.)
Attachments
Issue Links
- backported by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- documents
-
SERVER-40361 Reduce memory footprint of plan cache entries
-
- Closed
-