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(store): reset_data_pre_state_sync memory usage #3988

Merged
merged 4 commits into from
Feb 22, 2021

Conversation

mikhailOK
Copy link
Contributor

Add delete_all to StoreUpdate and implement it as a rocksdb range
delete. Use it in reset_data_pre_state_sync to clear ColState.

Test plan

unit test
existing tests

Add delete_all to StoreUpdate and implement it as a rocksdb range
delete. Use it in reset_data_pre_state_sync to clear ColState.

Test plan
---------
unit test
existing tests
core/store/src/db.rs Outdated Show resolved Hide resolved
Comment on lines +79 to +81
for shard_id in 0..self.caches.len() {
self.caches[shard_id].clear();
}
Copy link
Member

Choose a reason for hiding this comment

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

Are there any tests checking cache clearing / discrepancy between cache and column?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A discrepancy manifests itself as StorageInconsistentState: the invariant is that if a trie node is in cache+storage, then its children have to be there too, and forgetting to clear cache can break it.
At the moment ViewClient has its own cache and allows the error, and regular Client panics if it happens.

Copy link
Collaborator

Choose a reason for hiding this comment

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

what was the reason that we allow the error in view client (instead of cleaning the cache)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tracked by #3742. Two reasons:

  1. Invalidating the cache requires taking a lock and we don't want ViewClient to block Client
  2. The error is theoretically possible in ViewClient because it doesn't read from snapshots. Client is single threaded and the only one who can write to storage, so it doesn't have that problem. If we ever decide to use snapshots we can bring back feat(client): Read snapshots for state #3092.

@Kouprin
Copy link
Member

Kouprin commented Feb 22, 2021

store_update.delete_all looks very desirable. Thank you @mikhailOK.

Comment on lines +79 to +81
for shard_id in 0..self.caches.len() {
self.caches[shard_id].clear();
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

what was the reason that we allow the error in view client (instead of cleaning the cache)?

let cf_handle = unsafe { &*self.cfs[col as usize] };
let opt_first = self.db.iterator_cf(cf_handle, IteratorMode::Start).next();
let opt_last = self.db.iterator_cf(cf_handle, IteratorMode::End).next();
assert_eq!(opt_first.is_some(), opt_last.is_some());
Copy link
Member

Choose a reason for hiding this comment

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

would this be None any time

@mikhailOK mikhailOK merged commit b996461 into master Feb 22, 2021
@mikhailOK mikhailOK deleted the reset_data_pre_state_sync branch February 22, 2021 19:16
bowenwang1996 pushed a commit that referenced this pull request Mar 19, 2021
Add delete_all to StoreUpdate and implement it as a rocksdb range
delete. Use it in reset_data_pre_state_sync to clear ColState.

Test plan
---------
unit test
existing tests
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.

None yet

5 participants