Thursday, August 6, 2009

Graphing GC Events

Having been knee deep in tuning GC, trying to reduce GC pause time. Unfortunately Microsoft Excel, Apple Numbers, and OpenOffice Spreadsheet are all quite weak when dealing with the amount of GC and non-GC events we are trying to analyze, especially when it comes time trying to graph these events. Open Office on Ubuntu actually performed better, was able to deal with number of events that chokes both Excel and Numbers. However working with OpenOffice Spreadsheet is not the smoothed experience, as there are quite some rough edges here and there.

We've been using JConsole to watch live GC events, which is nice. If you can, always use JDK 6 JConsole instead of that from JDK 5. The former keeps history when JVM terminates, which is very nice.

Next we probably will investigate VisualGC (http://java.sun.com/performance/jvmstat/visualgc.html), VisualVM (https://visualvm.dev.java.net/), gchisto (https://gchisto.dev.java.net/). Hopefully one of them will turn out to be a better tool then pure spreadsheets.

Or, there is always JFreeChart or GnuPlot :-) One of our guys already used JFreeChat to plot some data, which actually looked quite nice.

Update on 08/07/2009:
Checked out VisualVM today along with its VisualGC plugin. The application itself looked pretty nice. However I was getting some kind of NullPointerException with the monitoring view, so there is no graph of heap usage etc. I am using Java 6 on Ubutnu, and I was having trouble get the VisualGC plugin to work with both of my remote JVMs. Of the the JVM is Java 5 32bit on Ubuntu, the other is Java 6 64 bit on Ubuntu. In both cases VisualGC was complaining it cannot work with the JVM version. Anyhow, from what I saw, I don't think VisualVM/VisualGC will give me the kind of graph that I was trying to do with spreadsheets, as I was plotting very detailed GC times for CMS initial mark, remark time, full GC, full GC from concurrent mode failure, and ParNew collections. Given that, I am still quite impressed with what I saw from VisualVM, and I am surely will visit it again the next time I need to dig into some other tough performance tuning problems.

No comments: