Appropriate sizing of heap and old gen for JVM for data heavy application

Question

• I am running a server application using JVM sunjava-1.6.0_21.
• My application is data heavy and acts as a cache server. So it stores a lot of long living data that we do not expect to get GC throughout the application is running.
• I am setting following JVM parameters -Xmx16384M and -Xms16384M.
• After the required data has been loaded, following is the memory usage of application
• Total heap space is :13969522688
• Maximum heap space is :15271002112
• Free heap space is :3031718040
• Long term (old gen) heap storage: Used=10426MB Max=10922MB Used/Max=95%

Old gen usage - I have confirmed that is due to actual data and is not expected to get free. My question is that by default JVM sizing of heap space ( it is allocating 10922MB old gen), that is leaving very little free space in old gen section.

• Can less free space in old gen impact the application?
• If yes, how should I handle this? Should I experiment with JVM tuning parameters like newratio and try to increase space available for old gen or any other way I should tune the application.

Answer 1

Can less free space in old gen impact the application?

If your Tenured Gen gets full a major collection will happened and this type of collection is costly. You can use the options : -verbose:gc and -XX:+PrintGCDetails to know if Full GC happend too often. If it's the case so yes it can impact the performance of your application.

If yes, how should I handle this? Should I experiment with JVM tuning parameters like newratio and try to increase space available for old gen or any other way I should tune the application.

You can give a try to NewRatio but keep in mind that if your eden is too short your tenured gen will probably get filled faster.

To conclude, you should use a monitoring tool to have a better idea of the VM options you have to use. It will show you easily how your generations are filled during the app execution, it's easier to read and understand than gc logs ;)

Answer 2

If you know that the length of life of your objects is that long play with the parameters that set the size of the regions in relation to each other.

You can set ratios in young generation and old generation (eden and ternured spaces) as well as both survivors.

The target is to minimize the full garbage collection by allowing the minor garbage collection to free all memory.

You prevent the garbage collection to free objects by keeping them reachable in your application. I mean that you should only care for those objects being deleted by minor garbage collections.

Enable the parameters

-verbose:gc -Xloggc:/opt/tomcat/logs/gc.out -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

Then with a tool GCViewer you can see time spent in gc and the number (size) of objects removed. Among some useful metrics.