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

Fix accounts_db store counts in purging accounts logic #8218

Merged
merged 2 commits into from
Feb 12, 2020

Conversation

sakridge
Copy link
Member

@sakridge sakridge commented Feb 11, 2020

Problem

When deleting, purge_zero_lamport accounts doesn't re-adjust the store counts once an account is determined not to be purged.

Summary of Changes

Take a pass to readjust the store counts before determining which stores can be purged.

Fixes #8130

@sakridge sakridge changed the title Fix ref counts Fix accounts_db store counts in purging accounts logic Feb 11, 2020
@sakridge sakridge requested a review from ryoqun February 11, 2020 19:38
@codecov
Copy link

codecov bot commented Feb 11, 2020

Codecov Report

Merging #8218 into master will increase coverage by <.1%.
The diff coverage is 100%.

@@           Coverage Diff            @@
##           master   #8218     +/-   ##
========================================
+ Coverage      82%     82%   +<.1%     
========================================
  Files         249     249             
  Lines       53530   53576     +46     
========================================
+ Hits        43913   43959     +46     
  Misses       9617    9617

}
}
if no_delete {
for (_slot_id, account_info) in account_infos {
Copy link
Member

Choose a reason for hiding this comment

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

I carefully re-read the purge_zero_lamport_accounts. And I think this new logic works as intended. Very nice and thank you so much! It's sad for me not to notice nor write this... ;)

My previous perception was wrong... Especially the DAG thing. I wonder why I was urged to think so. Maybe, too tired...

And this makes purge_zero_lamport_accounts yet more conservative. So, regardless a hostile or normal situation, I think accumulated zero lamport accounts impose us no-op wasted CPU time by bunch of loops for each snapshot_slot_interval to some extent.

Especially, this loop exhibits some contaminating/cascading behavior, easily approaching to the worst cost of O(N) where N is the total number of all updates to every accounts which became 0 lamport in the past at least once. That's because making no_delete be true for vast of unrelated pubkeys can easily be done by triggering the avalanche counting just with a single zero account with many updates.

In near future, I think we'd need some compaction mechanism as implied by #8168...

Copy link
Member

@ryoqun ryoqun left a comment

Choose a reason for hiding this comment

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

LGTM!

@mvines
Copy link
Member

mvines commented Feb 12, 2020

Is this a possible fix for #8168?

@sakridge
Copy link
Member Author

Is this a possible fix for #8168?

No, it's for #8130

@mvines mvines added the v0.23 label Feb 12, 2020
@mvines
Copy link
Member

mvines commented Feb 12, 2020

Sweet! Read to land? :shipit:?

@sakridge
Copy link
Member Author

Sweet! Read to land? :shipit:?

yea

@sakridge sakridge merged commit a8028fb into solana-labs:master Feb 12, 2020
mergify bot pushed a commit that referenced this pull request Feb 12, 2020
* Show insufficient purge_zero_lamport_account logic

* Add another pass to detect non-deleted values and increment the count

Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
(cherry picked from commit a8028fb)
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.

'Snapshot bank failed to verify', ledger/src/snapshot_utils.rs:462:9
3 participants