[Perf] Build rocksdb with jemalloc enabled #12
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.
Over time we have tested various performance-related RocksDB options that were recommended in the official documentation and different case studies compiled by its users, but most of the time the effect on snarkOS memory use hasn't been significant.
One of the greatest improvements wrt node RAM figures to date has been the switch from the OS allocator to
jemalloc
, which is much better at handling memory fragmentation and parallel workloads.It appears, however, that in order to utilize
jemalloc
within RocksDB specifically, it must be built with the seemingly undocumented jemalloc feature, which this PR does.Filing this as a draft, as there are 2 open points:
jemalloc
is currently included only for x86_86 Linux, so we may (on systems withoutjemalloc
it might just get ignored) need to tweak some TOMLs in order for it to work on other operating systems