cmd, core, eth, graphql, trie: no persisted clean trie cache file #27525
Conversation
rjl493456442
force-pushed
the
remove-trie-cache-journal
branch
from
5bcd639
to
12388f8
Compare
|
Performance wise, we will have a cache warm time if we get rid of the clean cache. The clean cache allowance is 614 mega bytes by default(mainnet). I think the cache Compare with the performance consideration, correctness is something we care more. E.g. https://github.com/ethereum/go-ethereum/blob/master/core/blockchain.go#L649 |
|
I kind of agree that this is a wonky mechanism and would be nice to get rid of it, but it's a non-trivial thing we added so it seems there probably was a good reason to do it in the first place. Could we benchmark the hit somehow? E.g. take 2 synced bench pairs, restart the machines (without starting Geth, to flush out any warm caches) and tehn start master vs. this PR and see what happens? |
The clean trie cache is persisted periodically, therefore Geth can quickly warmup the cache in next restart. However it will reduce the robustness of system. The assumption is held in Geth that if the parent trie node is present, then the entire sub-trie associated with the parent are all prensent. Imagine the scenario that Geth rewinds itself to a past block and restart, but Geth finds the root node of "future state" in clean cache then regard this state is present in disk, while is not in fact. Another example is offline pruning tool. Whenever an offline pruning is performed, the clean cache file has to be removed to aviod hitting the root node of "deleted states" in clean cache. All in all, compare with the minor performance gain, system robustness is something we care more.
rjl493456442
force-pushed
the
remove-trie-cache-journal
branch
from
12388f8
to
4bfd7ce
Compare
|
07 is this PR, without loading clean cache from file. The overall performance is not too different. And besides, the hit rate in clean hit is not very high, so I don't think this change will cause a big performance impact, should be good to go.
|
…hereum#27525) The clean trie cache is persisted periodically, therefore Geth can quickly warmup the cache in next restart. However it will reduce the robustness of system. The assumption is held in Geth that if the parent trie node is present, then the entire sub-trie associated with the parent are all prensent. Imagine the scenario that Geth rewinds itself to a past block and restart, but Geth finds the root node of "future state" in clean cache then regard this state is present in disk, while is not in fact. Another example is offline pruning tool. Whenever an offline pruning is performed, the clean cache file has to be removed to aviod hitting the root node of "deleted states" in clean cache. All in all, compare with the minor performance gain, system robustness is something we care more.
…file (ethereum#27525)" This reverts commit 2c0c010.
…file (ethereum#27525)" This reverts commit 2c0c010.
The clean trie cache is persisted periodically, therefore Geth can
quickly warmup the cache in next restart.
However it will reduce the robustness of system. The assumption is
held in Geth that if the parent trie node is present, then the entire
sub-trie associated with the parent are all present.
Imagine the scenario that Geth rewinds itself to a past block and
restart, but Geth finds the root node of "future state" in clean
cache then regard this state is present in disk, while is not in fact.
Another example is offline pruning tool. Whenever an offline pruning
is performed, the clean cache file has to be removed to avoid hitting
the root node of "deleted states" in clean cache.
All in all, compare with the minor performance gain, system robustness
is something we care more.