[SERVER-38815] Expose an absolute dirty size to the eviction configuration parameters Created: 03/Jan/19  Updated: 29/Oct/23  Resolved: 08/Sep/21

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

Type: New Feature Priority: Major - P3
Reporter: Dmitry Agranat Assignee: Josef Ahmad
Resolution: Fixed Votes: 3
Labels: louis-preferred
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-58144 Consider an absolute dirty size to th... Backlog
Related
related to WT-8030 Add sanity checks related to eviction... Closed
related to WT-3632 Increase how granularly cache usage s... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4, v4.2, v4.0, v3.6
Sprint: Storage Engines 2019-01-28, Execution Team 2020-05-04, Execution Team 2020-05-18, Execution Team 2020-06-01, Execution Team 2021-09-06, Execution Team 2021-09-20
Participants:
Case:

 Description   

Expose two configurable options that control the targeted and maximum levels of dirty data allowed in cache. The options will accept a floating-point value in gigabytes, like cacheSizeGB.

eviction_dirty_target can be thought of as the targeted amount of dirty data allowed in cache. Anything larger, and worker threads start eviction.
eviction_dirty_trigger can be thought of as a maximum amount of dirty data allowed in cache before application threads start eviction.



 Comments   
Comment by Githook User [ 08/Sep/21 ]

Author:

{'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}

Message: SERVER-38815 Expose an absolute dirty size to the eviction configuration parameters
Branch: master
https://github.com/mongodb/mongo/commit/46b7bdbc6a3d9a3e181bf5a1b8c2739c0dc80838

Comment by Geert Bosch [ 24/Jun/21 ]

I don't understand: a customer should be able to know the memory size of their server and configure an appropriate percentage. It would seem that expressing the value as an absolute number is just a shortcut to doing the computation for a specific configuration. I can see how it might make sense to use absolute values in some circumstances, but I fail to understand how it's more than a convenience. On a related note, it doesn't seem unreasonable to assume that checkpointing resource (in terms of IOPS and avalable compute power) scales to some degree with the memory size, so a 1 TB system should be OK writing 1 GB/sec while a 16GB system would be maxed out at 50 MB/sec. dmitry.agranat, could you give some clarification whether an absolute size is a convenience feature or more than that?

Comment by Dianna Hohensee (Inactive) [ 27/May/20 ]

So WT's solution in WT-3632 appears to have been to sort of overload all of the eviction settings. 0 to 100 values are considered percentages of cache; while >100 settings are consider an absolute size.

We do not pass eviction settings through MongoDB today. We won't change that. I will add a new MongoDB server parameter just for absolute dirty cache size.

Generated at Thu Feb 08 04:50:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.