[SERVER-23321] Allow pinning specific WT collections in memory Created: 23/Mar/16 Updated: 06/Dec/22 Resolved: 11/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage, WiredTiger |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Do | Votes: | 5 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| Description |
|
There are use cases that would benefit from the ability to keep an infrequently used collection in cache to reduce latency of queries to that collection. |
| Comments |
| Comment by Eric Milkie [ 11/May/20 ] |
|
Rather than adding the proposed knob, the recommended way of reducing paging is to adjust workloads or add cache memory. Certainly if a collection is read frequently, the eviction algorithm is already deprioritizing such pages when considering them for eviction. If the pages are still being evicted, the system must need that cache memory for other immediate purposes and preventing this eviction will lead to other problems. Pinning certain tables into memory such that the pages cannot be evicted can introduce new cache-full and eviction failure scenarios, so I am closing this as Won't-Do. |
| Comment by Hrushikesh [X] [ 28/Aug/18 ] |
|
We have a collection that goes through heavy read operation quite frequently. Due to other collections in the Mongo cluster being too large, the pages are getting evicted and read operations are reaching disk. This is a typical identities types collection which are accessed quite often by various modules in our product. |