This repository has been archived by the owner on Aug 2, 2022. It is now read-only.
database memory locking & hugepage support #6854
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Change Description
nodeos has historically only had one built-in way to use its database state files: as a memory mapped file. This PR adds two new modes of operation along with hugepage support on Linux. Users can switch between the three modes of operation on nodeos startup and all modes are compatible with each other such that no replay is required when switching modes. Motivation for this change is that database performance increases over 10% when using 1GB hugepages. There are some other interesting use cases too though, such as heap mode making it more practical to run nodeos on a HDD.
The modes of operation are:
Both heap and locked mode will require nodeos to write out entire database files on shutdown in addition to loading the entire database file on startup. These operations could take considerable time depending on database size and speed of storage.
Hugepage usage
By far the most interesting aspect of this change is hugepage support. Remember that hugepage support is only available on Linux and only available in locked mode of operation. Despite (at the moment) hugepages on Linux being non-swappable, nodeos still expects the
mlock()
call to succeed on the hugepages and thus the ulimit of the process will need to be set accordingly.nodeos will make use of the largest hugepage size it can without "over-committing". Some of examples of configuration:
On startup will see the output below because the 340MB size of the reversible database is not a multiple of the 1GB hugepage size:
If we were to change this configuration to
Then, since the reversible database is now a multiple of 1GB, on startup will see:
Another option though would be to specify multiple hugepage sizes:
Upon startup will see different page sizes being used:
This PR waiting on EOSIO/chainbase#33 first.
A note on the unit test: While I'm generally against POSIX stuff being added to the code base, the impression I got looking at some of the python unit tests is that there is some considerable dependency on POSIX behaviors there. The unit test here is a shell script which of course won't run on Win32... but much of the python unit tests won't either.
Closes out #6694
Consensus Changes
API Changes
Documentation Additions
See description above.