Skip to main content

Java Garbage Collection Question

2 replies [Last post]
Joined: 2009-01-19
Points: 0


We are seeing a behaviour in our production application for which i would like to seek your opinion. Our application is hosted on WebSphere Application Server v6.0 on a Solaris platform and uses Sun JRE 1.4.2_08.

We are seeing that a GC collection (minor) is happening every 2.5 seconds and the GC duration is very small, 0.04 seconds. Also the max heap size defined for the application is 1.0GB, we dont see the heap usage going beyond 600mb.Also, what i observed from the GC logs is that the Eden generation heap area is always around 100% and the tenured generation heap area increases from 35% to 100% in a matter of 1 minute. So two questions really,

1. Is it ok if the GC happens so frequently given that the pause is very less, 0.04 sec
2. Do we need to tune anything w.r.t the size of Eden Generation heap area?


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-07-11
Points: 0

> 1. Is it ok if the GC happens so frequently given
> that the pause is very less, 0.04 sec

yes, if the frequency and duration meet your needs.

> 2. Do we need to tune anything w.r.t the size of Eden
> Generation heap area?

You can decrease the frequency (and likely increase the duration) of
the minor GC events by increasing the size of the Eden and Survivor spaces.
-XX:NewSize/-XX:MaxNewSize/-XX:SurvivorRatio are the tunables you need.
If you increase the size of the young gen, though, you may need to increase your
overall heap size as well.

You didn't mention how much survives the full collection. If it returns back to to 35%,
then you have a lot of short lived data making it's way to the old gen, and a larger
Eden and Survivor spaces should give that data a chance to die in the young gen,
thus relieving the pressure on the old gen and reducing the frequency of the full

If the old gen utilization is slowly growing, then there may be some long lived objects
in your promotions. If this continues, then you may still take full gc events at some
frequency. If those full gc events prove to be too frequent or too long, then you might
want to do some heap profiling to see what those objects are and whether you expect
them to be long lived or whether they might represent a memory leak. If you can't
eliminate those objects, then you might consider switching to the CMS collector, which
can perform a significant amount of the old gen collection work concurrently with the
application running.

If the major collections always return you back to 35% utilization, then young gen
sizing may be all you need to avoid the full gc events.

If the full collections are happening exactly on 60s intervals, which I don't think is the
case here, then you may be dealing with the default RMI distributed GC operations,
which essentially result in calls to System.gc() every 60 seconds. You can test this
by adding -XX:+DisableExplictGC to the comand line. If this gets rid of 60s interval
full gc events, then consider tuning the RMI distributed gc frequency with the
supported -D properties (poke around on and you'll find
references to the appropriate properties).


Joined: 2008-05-23
Points: 0

1. The GC spends around 1.6% of the CPU given your figures (if 0.04s is the average time), so that seems reasonable. But you should consider full GC time which also cleans the Tenured Generation. If I understand well, the Tenured Gen reaches 100% every minute, so that you have a full GC every minute, which seems a bit frequently.
If your application has a commitment to absorb a high amount of requests per second, then full GC might be a problem because this is a "stop the world" action. You might then experiment the Concurrent Mark Sweep GC and Parallel New gC options, together with a big New Size (=increase Eden space). If you dont already, I suggest you use a graphical tool such as gcviewer to help you interpret the GC logs. You need to consider the GC throughput, which should be near 99%, the max and avergae pause time, frequency of full GC and their duration too.
2. The quickest answer is to try out and check, with 16MB for instance. But it really depends on your application requirements. The direct effect will be too decrease the number of full gC pauses, then decreasing your CPU load in %, but the drawback will be a RAM increase too.
Before you tune the Eden Generation, I suggest you use a memory profiler to check there are no anomalies such as too many collected objects for a certain class, memory leackage, etc.