aspose file tools*
The moose likes JSF and the fly likes Used heap size increasing continuous Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Used heap size increasing continuous" Watch "Used heap size increasing continuous" New topic
Author

Used heap size increasing continuous

Deniz Gol
Greenhorn

Joined: Oct 02, 2011
Posts: 6
Hello, I have jsf web application. I'm using jsf 2.1.9, hibernate 4.1.4, glassfish 3.1.2, primefaces 3.4.1. The problem is, used heap size is increasing slowly and after 2-3 days, reaches max heap size. then I must restart glassfish. heap dumps:
at the beginning, i clicked all web pages in application and used heap size was 100 MB:


after 1-2 days, used heap size is increased to 300 MB (same web pages used during this time):


I took screenshot of most used classes in heap. in my web pages, I generally select some objects from database and render it. here are some beans:
index:


gallery:


By the way, I have a mistake that I'm aware; I should not perform business logic in getters, but I think it is not the main reason of my problem. I need help and some advices. I can provide more information if you need, Thanks for your helps
Balaji Manoharan Bm
Greenhorn

Joined: Sep 22, 2013
Posts: 13
The issue is due to Old generation objects growing under load. But the root cause could be due to various reasons.

The below link will give you some idea
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Suspect the entities are getting piled up in application cache. Disable the second level cache and test once.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

I spent an entire month discovering the hard way that Oracle's "cache" did not adhere to one of the fundamental concepts of cache - limiting itself to a finite size by purging older entries. In short, the cache was "bottomless" - until the heap was exhausted.

The maddening thing about this was that the condition was occurring in a batch process that took 2-3 days to run, so I had to run a multi-day test, wait for it to bomb, analyze the results, then do it all again.

At the end, I found out that this was not a "bug" in either my logic or Oracle's. The behavior, though rude was documented, though obscurely. Very obscurely. If you knew what parameters to set, you could avoid the issue.


Customer surveys are for companies who didn't pay proper attention to begin with.
Deniz Gol
Greenhorn

Joined: Oct 02, 2011
Posts: 6
I did not enable second level cache in persistence.xml. I'm not using hibernate configuration file, here is my persistence.xml:

After Balaji Manoharan Bm's comment, I added this property too:

and it will not have any effect, we will see.
I also want to show you more things from heap dump:


In char[] class' instances, there are too much sql query string. I think Balaji Manoharan Bm is right, there is a problem with hibernate but where exactly ? I'm researching but it cost's to me much time.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

The reason why you should not place business logic in "getters" is that the overhead is ferocious. It's common for a property-get method to be invoked six times in a single page render request. The actual number of calls isn't easily predictable, but will almost always be multiple times. Database operations are very slow. Multiplying that by 6 is cruel and unusual punishment. Which is why when I need a "get" method to make a run for the database, I do it on the first request and cache the results. And, of course, the request must have no side-effects, since every "get" call should leave the state of the backing bean in the same condition.

Aside from that, though, why are you doing a "commit" on a database fetch? "commit" is what you use to formally apply changes to the data, not inquiries. And you definitely should not be doing changes to the database in a "get" method for the reasons listed above.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2447
    
  28

Congratulations on taking the heap dump. That's like half the battle right there.

In your heap dump, look at what those hash map entries contain. That will give you a clue. I'm not sure which tool you are using to do heap dump analysis there. I use MAT and in MAT you can click on a object and see outgoing references. This allows you to see the key value pairs in the hash map entry. Also, if you look at inbound references, it will tell you which hash map is holding that entry and which of your classes is holding that hash map.. You tool mig have some way of traversing the object graph that will give you more info.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Used heap size increasing continuous