Closed faddat closed 2 years ago
Merging #218 (e6d403a) into master (9ea19a1) will increase coverage by
0.02%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## master #218 +/- ##
==========================================
+ Coverage 68.51% 68.54% +0.02%
==========================================
Files 27 27
Lines 2128 2130 +2
==========================================
+ Hits 1458 1460 +2
Misses 595 595
Partials 75 75
Impacted Files | Coverage Δ | |
---|---|---|
rocksdb.go | 72.26% <100.00%> (+0.41%) |
:arrow_up: |
Impacted Files | Coverage Δ | |
---|---|---|
rocksdb.go | 72.26% <100.00%> (+0.41%) |
:arrow_up: |
In terms of benchmark, not yet.
Do you have any suggestions on benchmarking the performance of mainnet nodes? That is what I would like to benchmark.
Do we need to be concerned about expanding existing deployments' RAM footprint by a factor of approximately 4, if they were to patch this update? It seems like a lot of deployments depend on container orchestration. How does the operator know they need to bump up their RAM allocation (and possibly their instance sizes)?
RocksDB usage right now is solely experimental AFAIK, seems like a thing that can be communicated with a warning due to it not being actively used as of yet
I guess we'll see how it shakes out. 🙂
Today I'm working to make rocks an acceptable default, and this seems to help. I got some of this from terra's work on tm-db.
If desired, I could merge my version of this with more options illustrated for the user, but commented out:
https://github.com/notional-labs/tm-db/blob/rocks-tuning/rocksdb.go
I should also highlight Terra's work here:
https://github.com/tendermint/tm-db/compare/master...terra-money:performance
And finally I should mention that a company that specalizes in rocksdb performance enhancements has reached out to me. I bungled scheduling last week, reckon they will end up reading this PR, and hope to succeed with scheduling this week.
I figure it's helpful for me to show exactly what I am working on and with-- basically, Juno has has a longstanding sync issue. So I am trying to make it possible to do a pure-rocks node with Osmosis' iavl updates. This way, it'll be as easy as possible for people to set up archives.
I'm then going to go through every version of juno and apply the changes. So far, Terra's work seems to perform best.
Currently I am always talking in generalities. I am not sure what the best way to look at this stuff is:
Happy to compare notes with anyone.
Furthermore, it's notable that this will immediately apply to any 44 series chain, including osmosis and gaia.