[SERVER-76574] Improve LRUKeyValue to avoid storing keys twice Created: 26/Apr/23 Updated: 29/Oct/23 Resolved: 01/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | Matt Olma |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng, query-director-triage, quick-tech-debt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||
| Sprint: | QO 2023-05-15, QO 2023-05-29, QO 2023-06-12 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The LRUKeyValue utility is in-memory key-value store which guarantees that its size will never exceed a given budget, and which keeps itself under this maximum size budget using a least-recently used (LRU) eviction policy. It is currently used as the underlying data structure for the classic engine plan cache, the SBE plan cache, and the TelemetryStore. It is a template class where the keys are of type parameter K and the values of type parameter V. The callers use a pointer type for V (either a shared_ptr or a unique_ptr should work). In the case of the classic and SBE plan caches, K is the plan cache key itself which can be a quite large object. The problem is that LRUKeyValue actually stores multiple copies of each key object of type K: once in the list of key-value pairs which maintains the least-recently used ordering, and again in the hash table which is used for O(1) lookup by key. This doesn't matter much if the key is a small object like an int, but in practice we are storing multiple copies of a potentially quite large object like the classic or SBE plan cache key. We should improve this to store the key just once. |
| Comments |
| Comment by David Storch [ 30/May/23 ] |
|
matt.olma@mongodb.com this ticket can be closed now, right? |
| Comment by Githook User [ 27/May/23 ] |
|
Author: {'name': 'Matt Olma', 'email': 'matt.olma@mongodb.com', 'username': 'mattsimply'}Message: |
| Comment by David Storch [ 02/May/23 ] |
|
steve.tarzia@mongodb.com did you have any specific plans to schedule this? I know that plan cache memory consumption has been problematic for customers in the past, so I think this is worth trying to schedule in the relatively near future. Same thing for related ticket |