javamemory-managementmulejava-service-wrapper

Cannot get Mule 3.4.0 to utilize more than 4GB of memory


I'm currently working on a project which requires a large amount of memory, and I cannot get Mule 3.4.0 to utilize over 4gb of RAM (running on RHEL 6.2). I am using the Java HotSpot 64-bit server JVM 1.7.0_45-b18 and the community version of Mule.

I have been editing the wrapper.conf file and I have tried numerous settings to no avail.

I see there is a bug listed in the Mule JIRA: https://www.mulesoft.org/jira/browse/MULE-7018 which is closed against 3.4.0, but as incomplete.

My latest attempts have been to explicitly to try and force it to take up 8gb of heap space right away, the following being the latest attempt:

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=8192

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=8192

I have tried setting the initmemory and maxmemory paremeters to zero, in accordance with this old post about the wrapper: http://java-service-wrapper.996253.n3.nabble.com/4096MB-heap-limit-td1483.html - However, this causes mule to not start properly.

I have also explicitly tried to pass additional JVM parameters through the wrapper:

wrapper.java.additional.6=-Xmx8192
wrapper.java.additional.7=-Xms8192

When doing this, I can see both memory settings being sent to the JVM (i.e. -Xmx8192 -Xms8192 first on the process line followed by -Xms4096m -Xmx4096m). However, my top command yields no more than 4.2gb of resident memory being taken by the JVM process. I realize that the top RES column is not a 100% definitive way to determine JVM memory usage, but I am under the impression that if I'm trying to allocate 8gb out of the box, it should definitely exceed 4gb. The machine has 60gb physical memory.

Has anyone discovered a way to get more than 4GB of heap space for Mule 3.4.0?


Solution

  • I believe that Anton's answer will work just fine, however I couldn't clearly figure out when the Java Service Wrapper's license changed to GPL and didn't want to risk any negative implications of that change for my use case.

    I found a way to make this work using the current version of the Java Service Wrapper included in Mule 3.4.0, and thus not have any additional license implications with the JSW's change to GPL.

    If you modify wrapper.conf to explicitly set the min and max memory settings to 0:

    wrapper.java.initmemory=0
    wrapper.java.maxmemory=0
    

    Then you can pass the memory parameters directly via additional properties, also in wrapper.conf:

    wrapper.java.additional.6=-Xmx8192m
    wrapper.java.additional.7=-Xms4096m
    

    With the initmemory and maxmemory explicitly set to zero, the wrapper will no longer pass its own memory parameters to the JVM first, and thus allow you to specify your own. Note that this does not work for maxPermGen - for some reason the JSW still specifies its own value for that.