[close #751] Default MALLOC_ARENA_MAX new apps #752
Merged
Conversation
This file contains 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
schneems
force-pushed
the
schneems/malloc-arena-max
branch
from
655b06d
to
3959235
Compare
hone
reviewed
Apr 26, 2018
Closed
schneems
force-pushed
the
schneems/malloc-arena-max
branch
2 times, most recently
from
5f9b06a
to
d6a8796
Compare
calebhearth
approved these changes
Aug 20, 2018
calebhearth
approved these changes
Aug 20, 2018
schneems
force-pushed
the
schneems/malloc-arena-max
branch
3 times, most recently
from
fd5799f
to
c6e2235
Compare
|
Updated to only be new apps. I think this is good to go. I'm going to aim to merge after I get back from columbia. |
This PR will set MALLOC_ARENA_MAX=2 by default for new Ruby apps While we currently have [documentation on tuning the memory behavior of glibc by setting this environment variable](https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior) the default does not produce good results for Ruby applications that are using threads: - https://www.mikeperham.com/2018/04/25/taming-rails-memory-bloat/ - https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html In general most Ruby applications are memory bound and by decreasing the memory footprint of the application we can enable scaling out via more workers. Less memory might also mean a cheaper to run application, as it consumes fewer resources. Setting this value is not entirely free. It does come with a performance trade off. For more information, see how we originally benchmarked this setting: - https://devcenter.heroku.com/articles/testing-cedar-14-memory-use If a customer’s application is not memory bound and would prefer slightly faster execution over the decreased memory use, they can set their MALLOC_ARENA_MAX to a higher value. The default as specified by the [linux man page](http://man7.org/linux/man-pages/man3/mallopt.3.html) is 8 times the number of cores on the system. Or they can use the 3rd party [jemalloc buildpack](https://elements.heroku.com/buildpacks/mojodna/heroku-buildpack-jemalloc). Our documentation will be updated to reflect this change once the PR is merged and deployed.
schneems
force-pushed
the
schneems/malloc-arena-max
branch
from
9b5ad31
to
4f76122
Compare
|
Hey! How does this compare to jemalloc in ruby apps? |
This write up might help.. https://medium.com/@andresakata/benchmark-of-memory-allocators-on-a-multi-threaded-ruby-program-354ec4dc2e7e |
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 will set MALLOC_ARENA_MAX=2 by default for new Ruby apps
While we currently have documentation on tuning the memory behavior of glibc by setting this environment variable the default does not produce good results for Ruby applications that are using threads:
In general most Ruby applications are memory bound and by decreasing the memory footprint of the application we can enable scaling out via more workers. Less memory might also mean a cheaper to run application, as it consumes fewer resources.
Setting this value is not entirely free. It does come with a performance trade off. For more information, see how we originally benchmarked this setting:
If a customer’s application is not memory bound and would prefer slightly faster execution over the decreased memory use, they can set their MALLOC_ARENA_MAX to a higher value. The default as specified by the linux man page is 8 times the number of cores on the system. Or they can use the 3rd party jemalloc buildpack.
Our documentation will be updated to reflect this change once the PR is merged and deployed.