Wrong use of the memory options can cause serious performance problems. To optimize the right memory size of the JVM or to find some critical memory issues, the GC log of the JVM can be very useful. Simply start the Java application with the option -Xloggc:<file>. Every GC action gets logged into this file.
To analyse this log file, there is a nice tool called GCViewer, which can be downloaded from http://www.tagtraum.com/gcviewer-download.html. GCViewer is able to display the memory usage of the application based on time and old/young generation heap space.
First of all, the GCViewer displays the GC log from the time on where the JVM has started. This is mostly not very useful. Just right click on the top of the diagram and enable the start time of the log.
What kind of GC exists and how to optimize them, can be read from http://www.javaperformancetuning.com/tools/gcviewer/index.shtml. In this post, I will just tell you something about the GCViewer itself.
GCViewer creates two parts in the diagram. These parts are just logical and shows, how big the young and old generation heap space of your JVM are.
- The orange part is the young generation heap size.
- The purple part is the old generation heap size.
Every time the old generation heap size reaches it’s maximum, a full GC gets performed. A full GC is a vertical, black line in the diagram. (Remember: a full GC stops for a short time all activities of the JVM and cleans the old generation heap space. It’s very important to know that the bigger the heap size the longer the duration of a full GC!)
The duration of the GC is displayed as the green line at the bottom. You can see in the picture above, that the full GC consumes much more time than the young generation GCs.
I can recommend to log in critical environments your GC activities. If you run into som performance issues or response problems you can easily search for the reasons. It is a completion to the usual log file.
