You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GC = garbage collection
Right now GC first selects the number of blocks to delete, and then deletes everything that we can delete for that blocks. That means that GC limits (number of epochs to keep) are set by the most demanding columns. But not every column needs to be available the same number of blocks/epochs.
Why should NEAR One work on this
By introducing a separate limit for State and TrieChanges columns we can save disk space during high load. Notably, during first Cosmose onboarding we saw increase in RocksDB size of about 20GB per saved epoch. So, 100GB by default, and 200GB for internal nodes that were keeping 10 epochs. This was entirely due to garbage collectable State/TrieChanges data that we were keeping because of GC limits.
What needs to be accomplished
Implement separate configurable GC limit for State/TrieChanges.
[Optional] Implement separate configurable GC limit for every column.
Main use case
With this config option validators can decrease RocksDB size (and through this action also improve block production time).
Goals
Background
GC = garbage collection
Right now GC first selects the number of blocks to delete, and then deletes everything that we can delete for that blocks. That means that GC limits (number of epochs to keep) are set by the most demanding columns. But not every column needs to be available the same number of blocks/epochs.
Why should NEAR One work on this
By introducing a separate limit for State and TrieChanges columns we can save disk space during high load. Notably, during first Cosmose onboarding we saw increase in RocksDB size of about 20GB per saved epoch. So, 100GB by default, and 200GB for internal nodes that were keeping 10 epochs. This was entirely due to garbage collectable State/TrieChanges data that we were keeping because of GC limits.
What needs to be accomplished
Main use case
With this config option validators can decrease RocksDB size (and through this action also improve block production time).
Links to external documentations and discussions
Zulip thread about this idea.
Zulip thread about the relevant issue on mainnet.
Estimated effort
For the State/TrieChanges part of the project I expect 2-3 weeks effort from one engineer.
Assumptions
There are no specific assumptions that this project is making.
Pre-requisites
N/A
Out of scope
N/A
Task list:
to
to allow different GC restrictions for different columns. Both code snippets are gross oversimplifications of the actual code.
The text was updated successfully, but these errors were encountered: