Skip to content

Compress and linearise beacon blocks on disk #3583

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 4 commits into from
Closed

Compress and linearise beacon blocks on disk #3583

wants to merge 4 commits into from

Conversation

michaelsproul
Copy link
Member

Issue Addressed

Closes #3208

Proposed Changes

Very much WIP but this seems to be not too bad. Main TODOs are testing performance and providing backwards compatibility

@michaelsproul
Work in progress block separation
2bd784e
@michaelsproul
Squash merge of 3565
0c75da5 
Squashed commit of the following:

commit a4960eb
Author: Michael Sproul <[email protected]>
Date:   Mon Sep 12 12:10:23 2022 +1000

    Clippy

commit b28e8d0
Author: Michael Sproul <[email protected]>
Date:   Mon Sep 12 11:41:45 2022 +1000

    Add flag to disable prune on startup

commit de775d6
Author: Michael Sproul <[email protected]>
Date:   Mon Sep 12 11:19:21 2022 +1000

    Fix and update beacon chain tests

commit 2289b20
Author: Michael Sproul <[email protected]>
Date:   Fri Sep 9 17:40:21 2022 +1000

    Implement DB manager command

commit d5adc2e
Author: Michael Sproul <[email protected]>
Date:   Fri Sep 9 12:56:27 2022 +1000

    Implement on-demand pruning operation

commit 69d5474
Author: Michael Sproul <[email protected]>
Date:   Thu Sep 8 16:25:04 2022 +1000

    Delete finalized exec payloads while running
@michaelsproul
Use new frozen blocks
f0544b4
@michaelsproul michaelsproul added the work-in-progress PR is a work-in-progress label Sep 16, 2022
@michaelsproul
Copy link
Member Author

Syncing a new node with this code to see a) how big the database ends up and b) what the I/O pattern is like once backfill completes.

@michaelsproul
Copy link
Member Author

michaelsproul commented Sep 20, 2022 •
edited
Loading

This is looking good from a disk usage point of view, using only 48.1 GB after a few days (less than half what we currently use).

However the impact on I/O write amplification is not as good as I'd hoped, with only a ~10% reduction in gigabytes written per day. Data here: https://docs.google.com/spreadsheets/d/1-5ewstEFOQzHpoMLmlpWBBHBtJ7klSrjaVSmqwV7t0o/edit?usp=sharing.

I think the remaining writes are probably coming from hot states, which we write every epoch boundary. Using tree-states and the I/O queue idea I think we should be able to eliminate most of these (#2844).

@michaelsproul michaelsproul mentioned this pull request Oct 4, 2022
Merged
@michaelsproul
Copy link
Member Author

Closing as this is now merged into #3206.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
work-in-progress PR is a work-in-progress
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@michaelsproul