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

[FR] - Faster verification of on-disk cache #5500

Open
Fjodor42 opened this issue Oct 10, 2023 · 5 comments
Open

[FR] - Faster verification of on-disk cache #5500

Fjodor42 opened this issue Oct 10, 2023 · 5 comments
Labels
type: enhancement An improvement on the existing functionality

Comments

@Fjodor42
Copy link

Internal/External
External

Area
Other

Describe the feature you'd like
Drastic reduction of time needed for verification of on-disk blockchain state

Describe alternatives you've considered

  1. Parallelisation if the CPU-bound parts of the verification process
  2. Checksum-based checkpoints to skip through full verification of the full on-disk blockchain copy

Additional context / screenshots
For quite some time, using Daedalus, that Electron client will frequently revert back to the semblance of the start-up screen, with the point "Verifying on-disk blockchain state" showing 99.something percent, "Replaying ledger from on-disk blockchain" showing a low percentage, and "Syncing blockchain" showing 0.00%.

Remedy is restart of cardano-node.

This will, of course, trigger a verification of the on-disk blockchain state, which, on my system, pegs a single CPU core to 100%, but only reads from disk in "bursts" of between ~5MB/s to ~35MB/s, and the process takes several hours to complete.

Since a single core is utilised to 100%, and disk read speeds are low, it must be possible to parallelise parts of whatever it does, and it should also be possible to avoid actually reading the whole shebang on each (re-) start.

@Fjodor42 Fjodor42 added the type: enhancement An improvement on the existing functionality label Oct 10, 2023
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

@github-actions github-actions bot added the Stale label Nov 10, 2023
@Fjodor42 Fjodor42 changed the title [FR] - [FR] - Faster verification of on-disk cache Nov 10, 2023
@github-actions github-actions bot removed the Stale label Nov 11, 2023
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

@github-actions github-actions bot added the Stale label Dec 11, 2023
@ch1bo
Copy link
Contributor

ch1bo commented Jan 31, 2024

Maybe this could be resolved by allowing cardano-node to use all / more cores through the Haskell RTS options?

I heard somewhere that the node uses by default only two cores.

@Fjodor42
Copy link
Author

Fjodor42 commented Feb 1, 2024

Thank you, @ch1bo!

For me, specifically, I don't think I am using Docker, so would it be possible for me to just specify -N (or other options) somewhere in a config file?

Again, specifically for me, Cardano-node seems to actually be started by Daedalus Wallet on Linux.

@Fjodor42
Copy link
Author

Fjodor42 commented Feb 9, 2024

Update from my end: Having seen what I reported with cardano-node via Daedalus, actually getting cardano-node to pick up +RTS -N -RTS (I have since settled for +RTS -N8 +RTS) turned out to be rather involved, probably mainly due to my unfamiliarity with the system (NixOS) they rely on for making a single distributable package, so I shall spare you the details.

The relevant part for this thread is that not only does that speed up things considerably, but it also seems to work around another problem I had with cardano-node seemingly losing connection to mainnet, necessitating a process restart. Whether that is a function of this being run by Daedalus, however, is unknown to me.

Hence, I shall take my findings up with the Daedalus developers, and leave it up to to the cardano-node developers to decide upon whether to implement one or more of my suggestions - for them, it would probably still be relevant, though, to promote RTS options somehow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement An improvement on the existing functionality
Projects
None yet
Development

No branches or pull requests

2 participants