fix: dynamic batch size for tx lookup stage #3134
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We had some perf regressions on the tx lookup stage. A quick fix was implemented in #3128, but I think this fixes the underlying issue itself.
Essentially, we split the hashing work into batches. The size of these batches were determined by
100_000 / num_cpus
. Assume we are on a 16 core machine and the commit threshold of50_000
was retained.This gives us:
In other words, we are idling on half of our cores.
I think the reason #3128 alleviated this is because it would give us:
A more reasonable fix is to simply split the amount of available work across all threads evenly, i.e. if your commit threshold is 50k, then the batch size would be
50k / num_cpus
.This also brings the batching logic in line with the sender recovery stage.