Experimenting with Java Garbage Collection Options
Well... this morning I'm tinkering with Garbage Collection (GC) options for the JVM and I've seen two that look like they may have real promise to reduce these performance-robbing GC pauses in the current install on my development box. They are:
- -XX:+UseParallelGC - this guy is supposed to be a little more adaptive than the other, but it's got a limitation in that it can't function with some more advanced options. Alternatively, this guy is meant to work with very large heaps, which we have.
- -XX:+UseParNewGC - this guy is meant to be the successor to the other, and has no such limitations with more advanced features. The issue is whether or not it's really tuned to handle the larger Heaps, and if it's fixed algorithm is good enough.
What I'm hoping is just to get rid of the GC events where one CPU is pegged to 100% for more than a minute and everything else on the server just stops. If I can keep this guy running on a more even keel, it'll really help.
I'm running with the -XX:+UseParNewGC now and we'll see how it runs today. I can't believe it'll be worse, but the real question is will it remove the big pauses? We'll have to see.
UPDATE: I tried -XX:+UseParNewGC and I ran into the exact same issue. So I'm going to try -XX:+UseParallelGC and see if it's going to be any better. If not, I'll go back to the -XX:+UseParNewGC and see if I can try something else.
UPDATE: Yeah, the -XX:+UseParallelGC wasn't as good. I'm back to -XX:+UseParNewGC and Googling to see if there's something else I can try.
UPDATE: I saw this on Oracle's (Sun's) web site: it looks interesting:
java -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=8 \ -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31
with decent explanations of the options. The use of two different GCs is interesting, but they make the point that they are for different regions (young and tenured). Also, the target survivor ratio is at 90% - up from the default 50% making it more efficient on the long-term storage of which this app is heavily weighted.
More tests, hopefully these will look significantly better.
[5/14] UPDATE: In the end, the defaults were just as good, and while the memory footprint was a little bigger with the defaults, there were fewer pauses and the overall throughput of the application was better. In general, I guess they tune it about as well as it can be tuned. Shucks. But hey, it's "done", then.