-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Querying
-
None
-
Query Execution
-
(copied to CRM)
The query system has a cache of plan information. This cache is used to skip the expensive plan generation and selection process when there are many instances of the query that have the same shape. The following documentation page has further information:
https://docs.mongodb.com/manual/core/query-plans/
The current architecture involves a per-collection plan cache. Whenever the user creates a new collection, it has a new plan cache inside of it. This means that, for users with many collections, the collective size of the resulting plan caches can use a prohibitively large amount of memory. In order to control the total amount of memory used for plan caching, we need a central component with knowledge of all the memory allocated for plan cache instances. The easiest way to achieve this would be to change the architecture so that there is a single plan cache per mongod instance. This could be done internally, without affecting the interface presented by $planCacheStats, or the older plan cache introspection commands.
Note that this problem is compounded by SERVER-34886. A complete solution to the problem of plan cache memory consumption would likely require us to solve SERVER-34886 as well, by enforcing a maximum size of the global plan cache in bytes rather than enforcing a maximum number of entries.
- is related to
-
SERVER-34886 Plan cache size is bounded by number of entries rather than memory footprint
- Backlog
- related to
-
SERVER-40361 Reduce memory footprint of plan cache entries
- Closed
-
SERVER-40382 Add a serverStatus metric to report plan cache memory consumption
- Closed