state_machine: reduce memory usage by about 200 MiB #1429
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matklad
force-pushed
the
matklad/thinner-cache-map
branch
3 times, most recently
from
b40a869
to
13a5fcf
Compare
This one is tricky! The big picture here is that we have a cache of
objects, which is a normal cache with arbitrary eviction policy.
However, we want to maintain an invariant --- all objects touched by a
bar of events must not be evicted during this bar.
To achieve that, we place a stash below the cache. The job of a stash is
to catch all objects that fall out from the cache inside a single bar
(between bars, the stash is reset).
What's the size of the stash that we need?
The conservative estimate is the number of queries for the cache.
That is, inserts + lookups, and that is, using the old logic,
@as(u32, ObjectTree.Table.value_count_max) +
(options.prefetch_entries_max * constants.lsm_batch_multiple)
The insight of this commit is that a lookup and an insert _for the same
key_ are double counted that way.
In other words, what we are interested in is not the amount of queries
to the cache overall, but the amount of _different keys_ the queries
touch.
And for most of operations, we are actually going to update exactly the
keys we've prefetched.
The three exceptions are:
- lookup transfers
- lookup accounts
- fetching dependant transfer for posting/voiding
matklad
force-pushed
the
matklad/thinner-cache-map
branch
2 times, most recently
from
dcabfce
to
a3eb0a7
Compare
cb22
approved these changes
Jan 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This one is tricky! The big picture here is that we have a cache of objects, which is a normal cache with arbitrary eviction policy.
However, we want to maintain an invariant --- all objects touched by a bar of events must not be evicted during this bar.
To achieve that, we place a stash below the cache. The job of a stash is to catch all objects that fall out from the cache inside a single bar (between bars, the stash is reset).
What's the size of the stash that we need?
The conservative estimate is the number of queries for the cache. That is, inserts + lookups, and that is, using the old logic,
The insight of this commit is that a lookup and an insert for the same key are double counted that way.
In other words, what we are interested in is not the amount of queries to the cache overall, but the amount of different keys the queries touch.
And for most of operations, we are actually going to update exactly the keys we've prefetched.
The three exceptions are: