Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

avoid closure environment for mpt methods #2408

Merged
merged 1 commit into from
Jun 24, 2024
Merged

Conversation

arnetheduck
Copy link
Member

An instance of CoreDbMptRef is created for and stored in every account

  • when we are processing blocks and have many accounts in memory, this closure environment takes up hundreds of mb of memory (around block 5M, it is the 4:th largest memory consumer!) - incidentally, this also removes a circular reference in the setup that causes the AristoCodeDbMptRef to linger in memory much longer than it has to which is the core reason why it takes so much.

The real solution here is to remove the methods indirection entirely, but this PR provides relief until that has been done.

Similar treatment is given to some of the other core api functions to avoid circulars there too.

An instance of `CoreDbMptRef` is created for and stored in every account
- when we are processing blocks and have many accounts in memory, this
closure environment takes up hundreds of mb of memory (around block 5M,
it is the 4:th largest memory consumer!) - incidentally, this also
removes a circular reference in the setup that causes the
`AristoCodeDbMptRef` to linger in memory much longer than it
has to which is the core reason why it takes so much.

The real solution here is to remove the methods indirection entirely,
but this PR provides relief until that has been done.

Similar treatment is given to some of the other core api functions to
avoid circulars there too.
@arnetheduck arnetheduck merged commit 9521582 into master Jun 24, 2024
26 checks passed
@arnetheduck arnetheduck deleted the less-closure-env branch June 24, 2024 05:56
arnetheduck added a commit that referenced this pull request Jun 24, 2024
When processing long ranges of blocks, the account cache grows unbounded
which cause huge memory spikes.

Here, we move the cache to a second-level cache after each block - the
second-level cache is cleared on the next block after that which creates
a simple LRU effect.

There's a small performance cost of course, though overall the freed-up
memory can now be reassigned to the rocksdb row cache which not only
makes up for the loss but overall leads to a performance increase.

The bump to 2gb of rocksdb row cache here needs more testing but is
slightly less and loosely basedy on the savings from this PR and the
circular ref fix in #2408 - another way to phrase this is that it's
better to give rocksdb more breathing room than let the memory sit
unused until circular ref collection happens ;)
arnetheduck added a commit that referenced this pull request Jun 25, 2024
When processing long ranges of blocks, the account cache grows unbounded
which cause huge memory spikes.

Here, we move the cache to a second-level cache after each block - the
second-level cache is cleared on the next block after that which creates
a simple LRU effect.

There's a small performance cost of course, though overall the freed-up
memory can now be reassigned to the rocksdb row cache which not only
makes up for the loss but overall leads to a performance increase.

The bump to 2gb of rocksdb row cache here needs more testing but is
slightly less and loosely basedy on the savings from this PR and the
circular ref fix in #2408 - another way to phrase this is that it's
better to give rocksdb more breathing room than let the memory sit
unused until circular ref collection happens ;)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant