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.
- duplicates
-
SERVER-48400 Secondary node memory arise while balancer doing work
- Closed
- is related to
-
SERVER-34886 Plan cache size is bounded by number of entries rather than memory footprint
- Backlog
-
SERVER-40360 Process-global plan cache
- Backlog
- related to
-
SERVER-16895 Users should be able to request that explain not bypass the plan cache
- Open
-
SERVER-40382 Add a serverStatus metric to report plan cache memory consumption
- Closed
-
SERVER-51524 Alias internalQueryCacheSize to internalQueryCacheMaxEntriesPerCollection
- Closed