]
Brian Stansberry commented on WFCORE-2959:
------------------------------------------
Going with 1 sounds fine to me. In the description I said "this bears some
research/discussion" and that's happened now. :)
Export a low MALLOC_ARENA_MAX value in standalone.conf and
domain.conf
----------------------------------------------------------------------
Key: WFCORE-2959
URL:
https://issues.jboss.org/browse/WFCORE-2959
Project: WildFly Core
Issue Type: Enhancement
Components: Scripts
Reporter: Brian Stansberry
Assignee: Tomaz Cerar
This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in
cloud environments.
Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g.
{code}
export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1}
{code}
See
http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background.
The default glibc settings of allowing up to 128 malloc arenas make very little sense for
a java application, since the vm asks the os for a few large memory allocations and then
manages those areas itself. Leaving that default setting in place will result in a very
large virtual memory size for the VM. It's just virtual, not resident, memory, so
controlling this to a large extent is just a matter of having a better image for people
who don't understand the distinction. But as is mentioned in the linked blog
post's discussion of mlockall() and Elasticsearch, there may be some more concrete
implications as well.
The initial recommendation on this was to set the value to 1, but this bears some
research/discussion. For example hadoop uses 4
(
https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of
"MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3.