The current cache implementation bounds the number of cached elements by unit count. This works perfectly for constant-size elements, however when dealing with data with varying size (e.g., headers, ghostdag data, relations etc) it suffers from a size-estimation tradeoff -- on the one hand you want to estimate a unit size by its average case so that you allocate enough units for normal node operation, and on the other hand doing so might overfill the RAM when abnormal data arrives.
This pull-request implements a cache policy which includes a tracked mode which tracks dynamic data sizes. This way cache allocations can be monitored accurately resulting in tight management of resources also under abnormal conditions. The cache can now define a hard-bound limit in bytes and inserted/removed elements are tracked in real-time by their actual runtime memory requirements.
Remaining tasks:
Ideally add a cmd flag with an overall RAM bound which the user can provide (will be respected by consensus storage; will not guarantee other parts of the system)
coderofstuff
commented
6 months ago
The current cache implementation bounds the number of cached elements by unit count. This works perfectly for constant-size elements, however when dealing with data with varying size (e.g., headers, ghostdag data, relations etc) it suffers from a size-estimation tradeoff -- on the one hand you want to estimate a unit size by its average case so that you allocate enough units for normal node operation, and on the other hand doing so might overfill the RAM when abnormal data arrives.
This pull-request implements a cache policy which includes a
trackedmode which tracks dynamic data sizes. This way cache allocations can be monitored accurately resulting in tight management of resources also under abnormal conditions. The cache can now define a hard-bound limit in bytes and inserted/removed elements are tracked in real-time by their actual runtime memory requirements.Remaining tasks: