Search code examples
javagarbage-collectionjvmjvm-hotspot

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


  • 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.

Solution

  • 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 ;)