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

Refactor remove_uncleaned_slots to reduce memory consumption #2954

Merged
merged 2 commits into from
Sep 24, 2024

Conversation

dmakarov
Copy link

Problem

Cleaning algorithm creates many temporary data sets that consume significant amount of heap, increasing memory requirements of the validator.

Summary of Changes

Avoid making another temporary container of pubkeys that are candidates for cleaning.

This change reduces the used heap memory by 14% on a sample snapshot cleaning from 166,737,546,218 to 143,515,886,322 bytes.

Also collapse two small functions where the first is the only caller of the second into a single function, and remove a unit test that is almost a duplicate of another existing test that exercises the first of the functions.

@dmakarov dmakarov force-pushed the cleaning branch 2 times, most recently from 72d178b to 7cc70c2 Compare September 19, 2024 14:23
accounts-db/src/accounts_db.rs Outdated Show resolved Hide resolved
accounts-db/src/accounts_db.rs Outdated Show resolved Hide resolved
Copy link

@HaoranYi HaoranYi left a comment

Choose a reason for hiding this comment

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

Overall look good to me.
Just two suggestions.
Neither of them are blockers. They can be addressed in later PR if we want to.

&self,
max_slot_inclusive: Slot,
) -> Vec<Vec<Pubkey>> {
candidates: &[RwLock<HashMap<Pubkey, CleaningInfo>>],

Choose a reason for hiding this comment

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

I wonder if there is a case that we don't need filter "up_to_slot"?
If so, maybe we could make max_slot_inclusive Option?

/// returns the minimum slot we encountered
fn insert_pubkey(&self, candidates: &[RwLock<HashMap<Pubkey, CleaningInfo>>], pubkey: Pubkey) {
let index = self.accounts_index.bin_calculator.bin_from_pubkey(&pubkey);
let mut candidates_bin = candidates[index].write().unwrap();

Choose a reason for hiding this comment

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

nit: maybe we could sort and group the pubkeys by bins and insert all pubkeys to the same bin at once.
This will save the repeated costs of lock and unlock of the same bin, also we may have better cache locality.

Copy link
Author

Choose a reason for hiding this comment

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

I’ll make a follow-up PR. Thank you.

Copy link

@brooksprumo brooksprumo left a comment

Choose a reason for hiding this comment

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

:shipit:

Removing the extraneous allocation is a strict improvement over the current code.

@dmakarov
Copy link
Author

@jeffwashington should I wait for your review, or ok to merge?

@dmakarov dmakarov merged commit 651530a into anza-xyz:master Sep 24, 2024
40 checks passed
@dmakarov dmakarov deleted the cleaning branch September 24, 2024 14:21
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.

3 participants