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

Question

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?

Answer 1

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.

Answer 2

As the Jira ticket comments say, you can download a later version of the Tanuki wrapper (and replace the wrapper files included in the Mule standalone under lib/boot) to overcome this restriction. So, download Tanuki 3.3.0, remove all files with "wrapper" in their name under the Mule standalone lib/boot and subfolders, and replace them with the files included in lib and bin folders in the Tanuki wrapper. The Tanuki executable (bin/wrapper) goes under lib/boot/exec and the .so and .jar files under lib/boot. Mule should start normally, but unfortunately I can not test the 4G+ setting as I don't have a suitable machine available just now.

Answer 3

Tried to increase CompressedClassSpaceSize for a Mule Instance running as a Windows Service to no avail. The value would not get picked up until I finally figured out why.

I made the changes inside the wrapper.conf file by adding this line wrapper.java.additional.4=-XX:CompressedClassSpaceSize=2G (by the way 1G is default)

but failed to check wrapper-additional.conf file where .4 key was already taken, overriding my setting. I moved my change and modified the key value to the next consecutive number and voila: wrapper.java.additional.6=-XX:CompressedClassSpaceSize=2G

Some good commands to use: c:> tasklist | findstr java ...take a note of the PID... c:> jmap -heap

p.s. if you ever wanted to set this value starting Mule in standlone at cmd-line (as opposed to Service) then it will be c:> mule -start -M-XX:CompressedClassSpaceSize=2G

Happy coding!