I have a pure java process which is running on SUSE Linux installed on a VM (Vmware Virtual Machine). The max heap of java process is set to 128 MB.
What i am observing is,
Virtual memory consumed by this process is very high, more than 900MB.
The Resident memory is below 250MB.
The process is running for days without any OOM issue. So, there is no java memory leak.
The process does not use any JNI calls directly. So, chances of native memory leak is less (can happen only if JVM has some leaks).
I am not able to understand why the process is holding on to 900 MB of virtual memory. At present there is lot of swap space left on the machine.
Is the OS behaving lazy here by not reclaiming the virtual memory allocated to processes, until the OS runs out of virtual memory space?
More details about the process is given below -
The process spawns Java threads to handle incoming HTTP requests. I do not see any thread leaks (from thread dump).
It uses Java sockets to communicate to the back end in-memory cache store (Coherence).
Any suggestions on how to proceed with the investigation will be highly appreciated.
There’s a big difference between the heap available to a JVM and the
memory used by Java for that same environment. heap is always going to
be less, maybe a lot less, than what the system actually has in use for
the Java process itself. As an example, your ‘java’ binary, its
built-in JARs, and all of the libraries that interface with the OS
reside outside of the heap, and anything those use directly will be
outside the heap. The heap is only there for use by the JVM, which
doesn’t know/care about all of that stuff happening outside of it to
make it nicely cross-platform.
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
ab, thanks for the reply. I should have been more specific. What is concerning is not the difference between heap memory allocated and the virtual memory size. It is the constant growth in virtual memory of this process which is seen as an potential problem. The load on this process is same throughout the day, but the VM size keeps on increasing. Attaching a graph below, which shows the virtual memory growth of this process taken from collectl output - http://www.flickr.com/photos/unnisworld/6937446297/
From /proc//status i can see that it is VmData which is growing consistently.