[SERVER-73649] Improve SBE plan cache BudgetEstimator to incorporate the size of the key Created: 06/Feb/23  Updated: 29/Oct/23  Resolved: 02/Jun/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Maddie Zechar Assignee: Matt Olma
Resolution: Fixed Votes: 0
Labels: neweng, quick-tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-76574 Improve LRUKeyValue to avoid storing ... Closed
is related to SERVER-73659 Account for size of KVMap in LRUKeyVa... Closed
is related to SERVER-77976 Patch for calculation of SbePlanCache... Closed
Assigned Teams:
Query Optimization
Backwards Compatibility: Minor Change
Sprint: QO 2023-06-12
Participants:
Linked BF Score: 128

 Description   

The code for the SBE plan cache's BudgetEstimator currently looks like this:

struct BudgetEstimator {
    /**
     * This estimator function is called when an entry is added or removed to LRU cache in order to
     * make sure the total plan cache size does not exceed the maximum size.
     */
    size_t operator()(const sbe::PlanCacheKey& key,
                      const std::shared_ptr<const PlanCacheEntry>& entry) {
        // TODO: SERVER-73649 include size of underlying query shape and size of int_32 key hash in
        // total size estimation.
        return entry->estimatedEntrySizeBytes;
    }
};

That is, we are only considering the size of the PlanCacheEntry as counting towards the plan cache's memory budget. However, the keys themselves can get quite large – they encode a query shape which can get large, in addition to a bunch of other flags and index descriminators and such. The fact that we are not considering the size of the key means we are underestimating the memory being used by the SBE plan cache, and potentially using more memory than allowed by the planCacheSize parameter configuration.

Original description

Currently, SBE Plan cache budget estimations only track the size of the query plans. To be most accurate, we should also track the size of the hashed key and the underlying query shape (from which the hash is generated). This should be completed before before or in tandem with SERVER-73659



 Comments   
Comment by Githook User [ 02/Jun/23 ]

Author:

{'name': 'Matt Olma', 'email': 'matt.olma@mongodb.com', 'username': 'mattsimply'}

Message: SERVER-73649: Improve SBE plan cache BudgetEstimator to incorporate the size of the key
Branch: master
https://github.com/mongodb/mongo/commit/16b165a87f35ff60a12761cfa54ea2e25f8af54a

Comment by David Storch [ 26/Apr/23 ]

I filed SERVER-76574 about improving LRUKeyValue to avoid storing the key objects twice. I will change the ticket title and description to clarify that this is specifically about improving the SBE plan cache's budget estimator to account for the size of the key. I don't think we need to do anything for the classic plan cache, since it is currently bounded in size by number of entries rather than by number of bytes, so its budget estimator always returns 1. No action is needed for the TelemetryStore either since it already accounts for the size of the key.

Putting this ticket back into the triage queue. cc charlie.swanson@mongodb.com

Comment by Anton Korshunov [ 15/Feb/23 ]

I chatted with david.storch@mongodb.com about this ticket and SERVER-73659. Our thinking was that incorporating the size of a plan cache key does make sense to do. However, we were not sure about incorporating the internals of LRUKeyValue in the accounting, as proposed in SERVER-73659. If really want to do it, it would be good to understand first what it the actual overhead.

We also noticed that we keep two copies of the keys inside LRUKeyValue - one in _kvList and one in _kvMap and we'd like to fix that too.

Generated at Thu Feb 08 06:25:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.