Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-11565

Export a low MALLOC_ARENA_MAX value in standalone.sh and domain.sh

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Done
    • Major
    • 7.1.0.CR1
    • None
    • Performance, Scripts
    • None

    Description

      This is a task that came out of research done by rhn-engineering-anmiller on WF/EAP memory use in cloud environments.

      IMPORANT NOTE: This change is purely cosmetic; future versions of Java or JBoss EAP/WildFly may cause a large VIRT space to be reported; this is not a bug, it is just cosmetic.

      Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g.

      export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1}
      

      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.

      Windows scripts should not be changed. In domain, domain.sh will be updated, xml configuration don't need to be changed. For more information, see this comment

      Attachments

        Issue Links

          Activity

            People

              tomazcerar Tomaž Cerar (Inactive)
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: