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.