views:

150

answers:

3

We've recently migrated our systems from Sun Java 5 to Java6 server VM (specifically, 1.6.0_16 on Linux 32 bit). We've noticed that the garbage collection behaviour has changed in such a way as to trigger our heap-warning monitoring system.

The heap usage graphs indicate a much "spikier" memory usage profile than we saw with Java5, with the VM letting heap usage get very high before running a big GC. It doesn't appear to be a problem with the application system itself (it never actually runs out of memory), but it's giving the monitoring system the occasional spurious "hair on fire" signals whenever the usage spike approaches the threshold.

We could increase the heap max and hope the spike doesn't simply get bigger, but I'd much rather find out if there's a way we can tune the JVM parameters in such a way that we get a smoother profile, even if we loose a bit of performance.

I'm guessing there might be some -XX option we can set to achieve this, but I an't see any such thing in the docs. Anyone know of such an option?

+1  A: 

Can you confirm the same GC scheme/mechanism is employed? Do you calculate higher GC overhead in 1.6 or are pause times greater over any given duration?

Max and min heap free directives may help with some of your heap ergonomics too.

-XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio

http://java.sun.com/javase/technologies/hotspot/gc/gc%5Ftuning%5F6.html#generation%5Fsizing.total%5Fheap

Xepoch
There doesn't seem to be any noticeable performance impact. I fully expect that that Java6 uses a very different GC scheme to Java5, and I'm not especially picky about it; I just don't want it flying quite as close to the wire as it's doing.
skaffman
Scheme meaning that IIRC in Java5 folks surprisingly noticed parallel scavenge introduced by default if they had >1 CPU, but the defaults I *think* should be the same in 6 as in 5. You could rather try an incremental or optimized for throughput GC as that should roughly amortize the GC out a little more.
Xepoch
+2  A: 

It sounds like you would really like to have something more like a concurrent collection (as opposed to standard big-bang collections):

The concurrent collector is designed for applications that prefer shorter garbage collection pauses and that can afford to share processor resources with the garbage collector while the application is running.

Perhaps even more important, you should ensure that you're using the correct VM with the right options, over and above the specific garbage collection options. For example, I've tripped over the client vs. server VM issue multiple times in my own life.

Bob Cross
The Concurrent GC greatly improved the heap profile, and you're right, low latency at the expense of throughput does suit our apps better. Thanks for the suggestion, and have a cookie.
skaffman
@skaffman, cookie! ;-)
Bob Cross