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

Implement configurable fast node cache size #1163

Closed
2 of 8 tasks
p0mvn opened this issue Mar 27, 2022 · 1 comment
Closed
2 of 8 tasks

Implement configurable fast node cache size #1163

p0mvn opened this issue Mar 27, 2022 · 1 comment
Assignees
Labels

Comments

@p0mvn
Copy link
Member

p0mvn commented Mar 27, 2022

Context

There is a config iavl-cache-size that applies to both regular nodes and fast nodes. We would like to introduce a new config parameter specifically for fast nodes. Additionally, we would like to represent both parameters in bytes as opposed to the number of nodes.

Currently ,iavl-cache-size config is applied to every iavl substore (each module has its own substore). As a result, for every sub store we have 2 caches of the same max size - one for regular nodes and one for fast nodes.

While it might make sense to keep the same value for regular node, the current value is simply too large for fast nodes. As a result, we keep indefinitely populating fast node cache until OOM. That's why this separation is desired.

Some additional context here: #1140 (comment)

Currently, we hardcoded fast node cache to 100K: osmosis-labs/iavl#37

Plan Ahead

Work in Progress

Acceptance Criteria

  • implement a separate configurable value for fast nodes cache called iavl-fast-cache-size
  • represent both iavl-fast-cache-size and iavl-cache-size in bytes
  • find the best parameter for both that does not cause OOM while maintaining efficient performance
@ValarDragon
Copy link
Member

Lets move this to IAVL if we still want to pursue this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

2 participants