-
Notifications
You must be signed in to change notification settings - Fork 113
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
feat: update state:history storage to 1:1 #1561
Conversation
I wanted to get #1558 merged first and I would have started this topic myself :). I agree that 99:1 is broken and we should do something about it. Based on the discussion during meeting, my impression is that we want different ratio based on total storage capacity (different ratio for 100 MB vs 1 GB vs 10 GB). I also think that we should start measuring and dedicating some storage to Beacon as well. With this being said, I think that at the moment we don't have to do any special math, as we will have to redo it again, most likely soon. So I'm in favor of just doing 1:1 or even dedicating more storage towards history (as this is closer to actual current usage). Somewhat related to this, now that we have cli flags to specify storage per network, I would like to restart the discussion about enabling state network by default. My original concerns were:
So my only remaining concern is that state network doesn't have very useful data, yet. So if you or anybody else still feel like we should enable it, I wouldn't be against it. |
This approach to balancing storage will not last long. We will implement a more sophisticated approach in the near future. Rather than trying to guess what the state:history ratio will be, we can just look at it short term. If we add in the data from block 21M + 6 months, then the ratio gets to about 1:1. So technically we are still over-allocating for state right this moment, but it gives us plenty of runway, and is close enough that it shouldn't cause major problems.
f8cccf5
to
15a8ca4
Compare
Yeah, let's do 1:1 to just not overthink it. We can put the extra thought into whatever scheme we come up with next :)
Hah, yeah I spawned this PR when reviewing that one.
Yeah, looking back I was having a mini manic moment on trying to enable it then. I think it's pretty clear that the stability of state isn't really approaching history. So I at least would want to wait past Devcon. Some other reference points I might think about for calling it stable enough to turn on by default:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have strong feelings about what the new ratio should be. I just picked one, mostly to kick off discussion. Now, we have more information than we did at the 99:1 ratio selection.
The new ratio is still a loose guess. But it is based on some recently acquired state data, specifically:
A recent average amount of new state generated is about 1.75MB / block or ~375 GB per month. Let's make room for 10 years of intremental state at that rate, which gives us a network size of: ~45 TB.
The typical history node can fill up 35GB of storage with a ~2% radius, implying a network size of: ~1.75 TB.
45 TB / 1.75 TB ~= 25:1 ratio
Inspired by conversation and data collection here: https://discord.com/channels/890617081744220180/1089234065816821860/1300370058366947370