tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: What is the healthy interval length for young gc?
Date Mon, 03 Jan 2011 12:35:03 GMT
Leon Rosenberg wrote:
> Hi,
> First of all Happy and Successful New Year to all subscribers.

And the same to you.

> I understand that this is a very application specific issue, but I'm
> wondering which interval is perceived as 'healthy' for young
> collections?
> I have one customer's system which, at peak time, performs a young gc
> every 15 seconds. Parallel the response time goes incredibly high (>30
> seconds).
> So my questions are:
> Could it be that the long liveness of the objects in the young space,
> combined with often young collections lead to heap pollution on the
> old gen, cause request bound objects live to long?
> Do I understand it correctly that the size of the young space doesn't
> influence the collection time (as long as the amount of living objects
> remains the same) and does it make sense to increase the young space
> in our case?
Here is what I believe to be a nice article :

Of course, we really need Chuck to comment on this.
But let me tell you what I think, at the risk of stepping on my own fingers again.

I refer to the nice pictures in the above article.

The symptom that the response time becomes very long, makes me think that it is a Major GC

that is taking place often, not only a Minor GC.  I don't think that a Minor GC (involving

only the "new" Heap area) suspends the applications, while a Major GC does.

If Major GC's are taking place often, then it must mean that despite the regular copying 
from the "From" to the "To" parts of the new generation (by the Minor GCs), the JVM is 
running out of space on the new gen part, and therefore has to do a Major GC to move 
things to the "old gen".

By increasing the space on the new gen alone, you may make Minor GC's less frequent.

But if objects are being copied in the new gen between the From and the To, and the new 
gen is getting filled up rapidly anyway (since the Major GC's happen), it means that these

objects are still referenced somewhere and are not discarded during the copying.  So by 
increasing the new gen alone, you risk that when the Major GC does happen, it will fill up

the old gen too.  And if that one ever gets full, you will get an OOM.

So I would increase the Heap as a whole, and let Java determine the proper split between 
the parts.  And of course you can monitor what really happens, using a number of tools 
(like jconsole).

I do not think that the fact of copying the objects from the new gen to the old gen 
"causes the objects to live too long".  They live long because they are still being 
referenced somewhere and thus cannot be "forgotten".
So the real issue may be in the application, which is keeping references to objects, when

it shouldn't.
That may be a more difficult fix than some magic formula for Heap size.  But there have 
been a lot of discussions lately on the list about memory leaks, and maybe you can find 
inspiration there.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message