Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

a bit confused on heap dump results  RSS feed

 
alrem mashayekhi
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello based on analysis of a heap dump in our application, majority of the heap is consumed by:

90.32% 35,725 instances of java.util.HashMap$Entry

the thing is, we don't use hashmap in our codes, but we use hibernate though. is this because of hibernate? because this is built in on it? and there were too many queries in it? or is this likely coming from some other application residing in the app server?
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch.

How big is the JVM memory allocation? HashMap being a widely used class (not just by Hibernate, but throughout the JRE class libraries and in lots of other code), 35K entries seems like a low figure to me. Unless you're running into actual problems (as opposed to curiosity) I wouldn't pay it much attention.
 
alrem mashayekhi
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
max heap is 1.5GB and the heap dump generated were due to out of memory exception
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
90% of 1.5GB does sound excessive. If you look at the heap dump using something like VisualVM, you can see what kinds of objects are on the heap - whether they are in fact from Hibernate, or something else.
 
Chris Hurst
Ranch Hand
Posts: 443
3
C++ Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would recommend using Eclipse MAT (free) and running it's memory leak report, it will tell you which objects are retaining most memory and can break down by package etc should find hibernate quite quickly if it is that.

Alternatively use Visual VM and look at the 20 biggest objects by retained size, basically what you want to know what is retaining those hash map entries i.e. what are the GC roots (if no roots you ie no retained size you have a different issue ... you need to tune your collector), in Eclipse MAT you can ask it to identify the roots by retained size.
 
Jayesh A Lalwani
Rancher
Posts: 2762
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are using MAT, I highly recommend looking at the dominator tree. It shows the biggest objects by retained size, and allows you to drill into those objects. So, it will tell you what class is holding references to those hash maps.
 
Amit java
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jayesh A Lalwani wrote:If you are using MAT, I highly recommend looking at the dominator tree. It shows the biggest objects by retained size, and allows you to drill into those objects. So, it will tell you what class is holding references to those hash maps.


MAT is highly recommended tool, make sure your system has atleast 8GB RAM to parse this heap dump. MAT consume very high memory while parsing dumps and goes beyond 4-6 gigs.
 
Jayesh A Lalwani
Rancher
Posts: 2762
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've found that it's best if MAT is given the same amount of memory as the heapdump. For the most part, it works without any hiccup if it can load the whole heapdump into memory. It avoids trying to load everything into memory, but doing the kind of analysis that it does is not cheap. If you give it less memory, GC might start thrashing.

The above is just a rule of thumb. Not a hard and fast rule. I've loaded 16GB dumps by giving 8GB to MAT, and I've got stuck on 6GB dumps after giving 4GB to MAT. THe amount of memory needed by MAT depends on how large your reference tree is. If you have references going all over the place, MAT needs more memory. If you reference tree is neat and clean, then MAT need less memory because then it can load parts of the heap dump in memory while analyzing it. But, then again, if your reference tree was neat and clean, you probably wouldn't have a memory problem :p
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!