Skip to content
This repository was archived by the owner on Aug 2, 2022. It is now read-only.

Snapshot memory exhaustion - #9712

Merged
brianjohnson5972 merged 2 commits into
developfrom
bj_snapshot-memory-exhaustion
Nov 24, 2020
Merged

brianjohnson5972 merged 2 commits into
developfrom
bj_snapshot-memory-exhaustion

Conversation

@brianjohnson5972

Copy link
Copy Markdown
Contributor

Change Description

Code previously was batching up all key-value pairs from db intrinsic tables during initialization from a snapshot. Changed to track how much memory was being stored and writing out the batch when it passes a newly added configuration threshold.

Change Type

Select ONE

  • Documentation
  • Stability bug fix
  • Other
  • Other - special case

Consensus Changes

  • Consensus Changes

API Changes

  • API Changes

New configuration parameter:
"persistent-storage-mbytes-snapshot-batch"
Rocksdb threshold, in MB, to determine how much memory in Key-Value pairs to batch before writing data read from a snapshot. Depending on the resources available on your machine, increasing this number may result in faster loading of a snapshot.

Documentation Additions

  • Documentation Additions

"Rocksdb write rate of flushes and compactions.")
("persistent-storage-mbytes-snapshot-batch", bpo::value<uint32_t>()->default_value(config::default_persistent_storage_mbytes_batch),
"Rocksdb batch size threshold before writing read in snapshot data to database.")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do we really need a knob for something only used when reading a snapshot?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The intent was that having this means that if someone is using rocksdb because they have limited resources, that they won't be forced to have as high of memory available the we default to, but that if someone has plenty of memory, that they can jack it way up and start faster.
@tbfleming @larryk85 @b1bart

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't see any harm in having the knob. And it would allow for operators with more robust machines to set the value higher and read the snapshots in as fast as possible (bringing a reserve node up to parity or a main node back after failure).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

How much faster is it when turning the knob up?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I prefer to have a knob; fill-rocksdb had perf gains with high batch sizes (somewhere between 100-150 blocks of full-history deltas on mainnet). I no longer have the numbers, but the difference was large.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'll defer. I just believe we need to question every new knob as each and every one means additional testing and potential additional error reports when used incorrectly.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

My measurements with a mainnet snapshot:
50MB: 63s
200MB: 63s
1024MB: 61s

@brianjohnson5972
brianjohnson5972 merged commit 0d23b71 into develop Nov 24, 2020
@brianjohnson5972
brianjohnson5972 deleted the bj_snapshot-memory-exhaustion branch January 27, 2021 19:48
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants