Issue Summary

The thread discusses a memory management gap in WiredTiger where dhandle and cursor cache-related allocations are not currently counted against the configured WT cache size. This can allow total WT memory usage to exceed the intended budget and result in OOM kills, especially for users with a large number of tables.

Context

• geert.bosch@mongodb.com suggested reducing the WT cache size as a short-term remediation.
• geert.bosch@mongodb.com and keith.smith@mongodb.com raised the longer-term idea of billing variable WT allocations, such as dhandles and cursor caches, against the WT cache limit.
• keith.smith@mongodb.com noted that this would preserve WT's property of staying within its configured memory budget and degrade performance more gracefully under heavy dhandle usage, rather than risking an OOM.
• ivan.kochin@mongodb.com agreed this may be the right direction, but emphasized it is likely a larger effort and may introduce performance regressions if implemented naively.
• geert.bosch@mongodb.com clarified that MongoDB cannot know WT's memory needs beyond the allotted cache budget, and the goal is to avoid OOMs when users have lots of tables even if that reduces cache available for data.

Proposed Solution

• Investigate a change to include variable WT allocations (at minimum dhandle and cursor caches) in the WT cache accounting model.
• Evaluate the performance impact of reducing effective data cache in workloads with many tables.
• If needed, consider increasing default cache sizing to compensate for the additional accounted memory, while still keeping WT within a fixed total budget.
• Prioritize graceful degradation over OOM risk for users with unusually high table counts.

Additional Notes

The discussion suggests this is not a quick fix and may require broader design and performance analysis before implementation.

Original Slack thread: https://mongodb.slack.com/archives/C0C2LN7HQG4/p1790174013735339
This ticket was generated by AI from a Slack thread.