PS Old Gen memory in Heap Memory Usage: GC settings for Java Out Of Memory Exception

Question

Below are my JVM settings:

 JAVA_OPTS=-server -Xms2G -Xmx2G -XX:MaxPermSize=512M -Dsun.rmi.dgc.client.gcInterval=1200000 -Dsun.rmi.dgc.server.gcInterval=1200000 -XX:+UseParallelOldGC -XX:ParallelGCThreads=2 -XX:+UseCompressedOops  -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jbos88,server=y,suspend=n

Problem: Total Heap Memory: 2GB Old Gen: 1.4GB (2/3 of Heap) New Gen: 600MB(1/3 of Heap)

The Old Gen grows in memory beyond 70% 0f its allocated size and never is subjected to GC even at 100% i.e 1.4GB. One can see the graph below it peaks and never is GC, the drop in memory is when it was forced to GC from the JConsole. This problem is eventually bringing the web server down.

Anything that i am missing or wrongly setting the JVM?

Thanks for the help in advance.

Updating my Question:

After heap analysis it appears like Stateful session bean is the prime suspect: We have stateful session beans that hold the persistence logic assisted by Hibernate.

Eden

do you see JVM termination with OutOfMemoryError Heap Space ? or you are expecting old gen GC to run earlier ? – Supplemental

Answer 1

The stateful session beans were making the JVM run out of memory. Explicitly handling them using @Remove annotation resolved this issue.

Eden

How did you find it? – Suint

Answer 2

The GC will be called eventually, the old gen is almost never called (because it is extremely slow). The GC does run but it will only run on the new gen and survivor gen at first, it has a completely different algorithm for cleaning the old gen which is slower then new/survivor gens.

Those numbers are really high, the oldgen should never reach sum a high number compared to the newgen. My guess is that you have a memory leak.

I can only guess your program is dealing with big files, you are probably saving references to them for too long.

Weeds

Answer 3

Even still having the main problem (memory leak) resolved, if you still want the old gen to be cleared in frequent small sized pauses, you may try setting

-XX:MaxGCPauseMillis=(time in millis)

and this is only applicable with Parallel Collector and when Adaptive Sizing Policy is on. By default Adaptive Sizing Policy is on, but, if you want to explicitly mention this you can use.

-XX:+UseAdaptiveSizePolicy

Or else you can switch to CMS collector where you can use

-XX:CMSInitiatingOccupancyFraction=(% value) 
-XX:+UseCMSInitiatingOccupancyOnly

Which is a more reliable way of collecting the old gen when it has reached a certain fraction of the the old gen.

Zebrass

I tried these JVM parameters and apparently GC is not able to free the old gen space and keeps rying to free the memory forever each time able to recover hardly any memory. – Eden

If memory is not recovered significantly after a full gc, then what is in your old gen is not garbage. In that case this can be the memory footprint of the application. If so, you should consider increasing the total memory allocated. Assuming Stateful Session Beans are the main occupants of the memory, I would say the memory foot print approximately equals to ( rate of creating new sessions * session timeout * avg size of a session ) – Zebrass

Why don't you share the another analysis of heap after doing the optimizations (@Remove annotation) ? so I will have a better picture of the situation. I would love to see the output of jmap -histo:live <pid> – Zebrass

attached the jconsole after the changes were done to the session bean....the one where it dropped to 0MB please ignore i had restarted the server... – Eden