Menu
I am experiencing memory leak and here goes some detail.
At the time of after-leak,
At the time of before-leak,
I am pretty surprised that the difference between top, heap-dump size, and the actual heap size. I am guessing that the difference between top and heap is the possibility of garbage collector heap and native heap areas. But, how come the heap dump file size and the actual heap size (from eclipse MAT analyzer) could differ?
Any insight on this problem?
UPDATE / ANSWER
Some of suggestions are to use jcmd (https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html) as the website tells "Native Memory Tracking". But, if you read the page carefully, you will see
Since NMT doesn't track memory allocations by non-JVM code, you may have to use tools supported by the operating system to detect memory leaks in native code.
So, in case of the leak inside the native library, jcmd is not an option.
After crawling the Internets for days and trying out various profilers, most effective for this problem is using jemalloc profiler.
This page helped me a lot! https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/
922
In my experience, having a heap dump much smaller than the real memory used can be due to a leak in the JNI. Despite you don't use directly any native code, there are certain libraries that use it to speed up. In our case, it was a Deflater and Inflater not properly ended.
What is the heap dump file size? The heap dump file size is actually 382 MiB.
We will first start the Memory Analyzer Tool and open the heap dump file. In Eclipse MAT, two types of object sizes are reported: Shallow heap size: The shallow heap of an object is its size in the memory. Retained heap size: Retained heap is the amount of memory that will be freed when an object is garbage collected.
If you are trying to test memory leakage in your application all you have to do is to identify the object which gets accumulated in the heap every time you access the application. To effectively identify the objects first take and initial heap. Then perform some action in your application.
top and other OS level tools show how much system memory does your JVM process consume. Java heap, defined by -Xmx command line option, is only a part of that memory. Apart from heap JVM needs some memory for itself. Then there are java threads, each requiring a certain amount of memory. And Metaspace/Permanent Generation. And several others. You can read this blog post and this SO answer for more information.
About the size of the dump file and the actual heap size the answer of @arnab-biswas is certainly true. MAT reports the size of actually used heap, consumed by live objects. But heap dump contains the whole of the heap, including garbage.
105
I have experienced similar situation. The difference (HPROF file size - Size of the heap indicated by MAT) is effectively garbage (unreachable objects). Unreachable object Histogram in MAT should help here.
jmap -F -dump:live,format=b,file=<file_name.hprof> <process_id> will only dump live objects and NOT garbages.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
