util/buffer_pool, db: Reduce memory allocation#367
Merged
syndtr merged 2 commits intosyndtr:masterfrom Aug 19, 2021
Merged
Conversation
The sync.Pool implementation in go std library has improved drastically since the buffer pool used here has been first implemented. Using sync.Pool results in drastic memory reduction as well as a simpler buffer_pool code.
Instead of allocating new memory with make() for db_compaction writing, fetch from the buffer pool and return it when finished, reducing memory allocation.
Owner
|
Merged. Thank You! |
kcalvinalvin
added a commit
to kcalvinalvin/btcd
that referenced
this pull request
Sep 4, 2021
Goleveldb recently had a PR in where memory allocation was reduced drastically (github.com/syndtr/goleveldb/pull/367). Update goleveldb to use that PR.
kcalvinalvin
added a commit
to kcalvinalvin/btcd
that referenced
this pull request
Nov 17, 2021
Goleveldb recently had a PR in where memory allocation was reduced drastically (github.com/syndtr/goleveldb/pull/367). Update goleveldb to use that PR.
kcalvinalvin
added a commit
to kcalvinalvin/btcd
that referenced
this pull request
Nov 17, 2021
Goleveldb recently had a PR in where memory allocation was reduced drastically (github.com/syndtr/goleveldb/pull/367). Update goleveldb to use that PR.
This was referenced Nov 23, 2021
jcvernaleo
pushed a commit
to btcsuite/btcd
that referenced
this pull request
Nov 30, 2021
Goleveldb recently had a PR in where memory allocation was reduced drastically (github.com/syndtr/goleveldb/pull/367). Update goleveldb to use that PR.
roylee17
pushed a commit
to lbryio/lbcd
that referenced
this pull request
May 24, 2022
Goleveldb recently had a PR in where memory allocation was reduced drastically (github.com/syndtr/goleveldb/pull/367). Update goleveldb to use that PR.
asheswook
pushed a commit
to asheswook/btcd
that referenced
this pull request
Apr 2, 2026
Goleveldb recently had a PR in where memory allocation was reduced drastically (github.com/syndtr/goleveldb/pull/367). Update goleveldb to use that PR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR addresses the problem of too much memory being allocated by goleveldb in the project I'm working on here: https://github.com/mit-dci/utcd.
I've conducted two benchmarks to check that this PR lessen the memory allocated:
1: pprof results from the project I'm working on.
2: Benchstat results from the existing benchmark tests in goleveldb.
pprof results
The project I'm working on is a Bitcoin node in Go. It uses goleveldb to keep track of Bitcoins that are available to be spent. The load on goleveldb is very intense with there being many reads and writes when it first starts up. I used this command to create a controlled test for profiling the memory usage.
The binary used was compiled from branch
utreexoon commite1ab5c048f37e714b46e94782c4e2a66319962f2pprof-top results
Before,
BufferPool.Get()allocated the most memory. 45.19% of all memory allocated was allocated by it.After,
BufferPool.Get()only allocated 9.12%.old:

new:

pprof-flame results
The difference of the memory allocated between these two can be visibly seen on the flamegraph as well.
old:

new:

I've included the html files for the pprof images used above as well as the html files for pprof-graph
pprof goleveldb.zip
Benchstat results
The benchmarks were separated into the following:
DBRead,DBWrite,DBSeek,DBOverwrite,DBPut, andDBGet.The actual benchmarking was performed with the following command:
In some there was a lot of variation so the results might not mean much for those specific benchmarks.
Biggest improvements
While most of the benchmarks showed no real difference, the biggest wins were from the following:
Some extra memory allocation during the benchmarks
There were more memory being allocated for some tests. These are:
Full Benchstat results
For the use case of the project I'm working on, this PR was an immense improvement. From the benchstat results, we can assume that it would be an immense improvement for other projects as well.