Skip to content
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: add ETL to Hashing Stages #7030

Merged
merged 12 commits into from
Mar 26, 2024
Merged

feat: add ETL to Hashing Stages #7030

merged 12 commits into from
Mar 26, 2024

Conversation

joshieDo
Copy link
Collaborator

@joshieDo joshieDo commented Mar 7, 2024

ref #6909

When taking the code path of hashing every account/storage (aka clean hashing), it now uses ETL without comitting inbetween.

Mainnet

AccountsHashing

  • 34min -> 2min24s
  • 17.9GiB -> 12.2GiB

StorageHashing

  • 1h23min -> 53min
  • 82.9GiB -> 61.1GiB

Holesky @ 1M

AccountsHashing

  • 142 seconds -> 9 seconds
  • 1.4GiB -> 981 MiB

StorageHashing

  • 108 seconds to 34 9 seconds
  • 1.3GiB -> 991 Mib

@@ -356,91 +310,6 @@ mod tests {
assert!(runner.validate_execution(input, result.ok()).is_ok(), "execution validation");
}

#[tokio::test]
async fn execute_clean_account_hashing_with_commit_threshold() {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clean hashing execution no longer relies on commit_threshold

@@ -310,156 +263,21 @@ mod tests {
}
}

#[tokio::test]
async fn execute_clean_storage_hashing_with_commit_threshold() {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clean hashing execution no longer relies on commit_threshold

@joshieDo joshieDo marked this pull request as ready for review March 14, 2024 16:27
Copy link
Member

@gakonst gakonst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM -- would like @onbjerg & @mattsse to quickly inspect, and if good let's move on to the indexing stages as well.

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

less code good

we could also limit the rayon global pool instead, but should definitely restrict how many cores we're using for this, this could be integrate in the stages builder setup where the pool is then shared with the relevant stages

Comment on lines +176 to +177
// Spawn the hashing task onto the global rayon pool
rayon::spawn(move || {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this has the same issue as sender recovery stage,

what we could do instead is add a pool that has < available_parallelism() threads

this would also solve the sender recovery issue I believe,

ref

std::thread::available_parallelism()
.map_or(25, |cpus| max(cpus.get().saturating_sub(RESERVED), RESERVED))

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree @joshieDo

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#7267

should take care of it

@joshieDo joshieDo requested a review from mattsse March 21, 2024 13:51
Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that makes sense to me

pending @shekhirin

Comment on lines 170 to 177
let mut channels = Vec::with_capacity(10_000);

// itertools chunks doesn't support enumerate, so we use a counter to know when to flush
// hashes from channels to disk.
let mut flush_counter = 1;

// channels used to return result of account hashing
for chunk in &accounts_cursor.walk(start)?.chunks(100) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where are these numbers coming from?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made a few changes, but they're arbitrary. I tried this in some benchmarks, and didn't have apparent performance degradation. We might want to tweak them in the future though.

Before we were just pushing all channels into vec, which would grow the memory usage immensily. So batching and flushing seems a more reasonable approach.

Copy link
Collaborator

@shekhirin shekhirin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, logging nit

@joshieDo joshieDo added this pull request to the merge queue Mar 26, 2024
Merged via the queue into main with commit 96e39d2 Mar 26, 2024
27 checks passed
@joshieDo joshieDo deleted the joshie/hashing-stages-etl branch March 26, 2024 16:58
Ruteri pushed a commit to Ruteri/reth that referenced this pull request Apr 17, 2024
Ruteri pushed a commit to Ruteri/reth that referenced this pull request Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants