Java – Why is the java process using much more heap space than specified

javamemory usagesolaris

I'm running a Java application on Solaris using the -Xmx256M switch. When I connect via JMX, the JVM tells me the application is using about 50Mb of heap, and correctly states the maximum heap size is around 250Mb.

However, Solaris is telling me a very different story. When running pmap, for example, I get:

 ~ > pmap -S 10124 | grep heap

0002C000    3920    3920 rwx--    [ heap ]
00400000  815104  815104 rwx--    [ heap ]

Showing an incredible 800Mb of memory being used for heap space.

ps confirms the memory usage:

ps -eo vsz,rss,pid,args | sort -n

939368 925576 10124 /apps/../java -Xmx256M xxxx

I've read https://plumbr.eu/blog/why-does-my-java-process-consume-more-memory-than-xmx, but the article describes JVM using memory other than heap (i.e. stack, native libraries and threads) – but in my case, the JVM is actually using much more heap than specified.

My java version is:

java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) Server VM (build 20.6-b01, mixed mode)

To add to the mystery, I have other Java applications running on the same box, using the same JVM with the same settings, that behave perfectly fine. What makes this application "special" is that it connects to an external third party application (RET LBN, if that helps). It does not run any JNI or native code – so why is the third party library not respecting the JVM's startup parameters?

I'm at my wits end – any help or pointers will be greatly appreciated.

Best Answer

The Java heap is a block of memory that holds java objects.

"pmap" shows the Operating System process heap. This is the memory used to run the java process. This includes all the java code, plus all the C code that makes up the java run time environment.

To show the java heap try Memory tab of jconsole, or jmap or jstat.

Related Solutions

Java – What resource limit is Java encountering on the Solaris server

You are clearly running out of swap space. The fact you still have free RAM is unrelated. Solaris isn't overcommitting memory so all the reservations must be backed by virtual memory.

Have a look at swap -s output to get information about virtual memory (a.k.a. swap) usage.

Java – Large virtual memory size of ElasticSearch JVM

I'm pretty sure that the answer you got from the ElasticSearch community relates to the ZFS ARC (Adaptive Replacement Cache). This of course assumes that your file system is ZFS?

On ZFS the ARC will potentially take up all of the available RAM on the host less 1 Gb. So on a ZFS host tools like top will sometimes show that your physical RAM is close to the limit even if it isn't. This is by design. The ARC will automatically release memory to processes that need memory. What memory the ARC uses counts as kernel memory so you can't really see it in a process output.

On most of the Solaris systems that I look at daily the physical RAM consumption is about 90%. This is not because they are very utilized, it is the ZFS that grabs unused RAM for its own purpose. Don't be alarmed by this. As the ARC is part of the kernel it can release memory to processes that need it at the speed of the light so to speak. Hence - although you can - I typically do not see a point in limiting the size of the ZFS ARC. Better to let ZFS do its job.

So, if we're talking about ZFS, then yes, file system caching doesn't show up as memory consumption on an individual process. You'll need to execute something like:

echo "::memstat" | mdb -k

to reveal how your memory is actually used. The line "Anon" covers all the user land processes that you see in e.g. prstat output.

The other thing for you to know is how the JVM works in terms of memory allocation and release of memory. The JVM grabs memory from the OS as it needs it only restricted by the JVM -Xmx command line parameter. The open question is how (if ever) the JVM will release memory back to the OS if it no longer needs it ? You'll find that is is very difficult to find information on this subject. It seems to depend on which garbage collector is used. As it is difficult to get precise information on this subject (don't know why really) your best option is to assume that the JVM is extremely reluctant to release memory back to the OS. In other words : if you allow a JVM process to grab say 50 GB memory then you better be in a position where you can afford this permanently rather than assuming that this is just a burst.

So if you want to limit how much memory the ElasticSearch process can consume then you need to look into the JVM command line parameters, in particular the -Xmx option.

Related Topic