Conversation
| if pruneTimeout := remainingPruneTimeout(); pruneTimeout > 0 { | ||
| if _, err := tx.(kv.TemporalRwTx).PruneSmallBatches(ctx, pruneTimeout); err != nil { | ||
| return err | ||
| } |
There was a problem hiding this comment.
how removing
if s.CurrentSyncCycle.IsInitialCycle {
pruneTimeout = 12 * time.Hour
}
will work on non-chain-tip (i mean when re-exec from 0)?
There was a problem hiding this comment.
I think you miss-understand issue. problem is not prune > 2s problem is prune has 12 hours timeout if existing synced node restart (because s.CurrentSyncCycle.IsInitialCycle) is true. And it has 12 hours timeout because - how else we can prune data on non-chain-tip (when executing from 0)
There was a problem hiding this comment.
how else we can prune data on non-chain-tip (when executing from 0)
After some creating and merging changeset and other files why not? Also, you've mixed here 2 different situations (sync from 0 and restart on synced node), so I don't get what we're discussing. However, on exec prune u shared I saw spike to 9s after restart (on ottersync it was ~1min)
There was a problem hiding this comment.
how removing
if s.CurrentSyncCycle.IsInitialCycle { pruneTimeout = 12 * time.Hour }will work on non-chain-tip (i mean when re-exec from 0)?
It will attempt to prune "small batch" in a time every time we will enter the exec function (in exec prune) same for all stages, eventually it will prune all
There was a problem hiding this comment.
ou've mixed here 2 different situations (sync from 0 and restart on synced node).
We don't have in Erigon code separation of this 2 cases.
And this is a problem.
s.CurrentSyncCycle.IsInitialCycle is true in both cases.
if your PR remove
if s.CurrentSyncCycle.IsInitialCycle {
pruneTimeout = 12 * time.Hour
}
it also will affect 2 cases.
There was a problem hiding this comment.
But my PR don't remove this cond anyway.
There was a problem hiding this comment.
Synced node hasn't InitialSync true as I saw, no?
There was a problem hiding this comment.
Oke, will sync to tip and check var after restart
…es/quickprunetocondfixes
2 participants
closes #20854
Simplifies execution prune timeout handling by using one shared stage-level budget across changeset pruning, block access list pruning, and small-batch pruning.
On chain tip, the quick timeout is no longer refreshed per prune step, so Ethereum execution prune uses one shared 2s budget instead of up to 2s per operation. Initial-cycle pruning keeps the long aggressive budget.