tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <Chuck.Caldar...@unisys.com>
Subject RE: What is the healthy interval length for young gc?
Date Mon, 03 Jan 2011 14:23:13 GMT
> From: André Warnier [mailto:aw@ice-sa.com] 
> Subject: Re: What is the healthy interval length for young gc?

> I don't think that a Minor GC (involving only the "new" Heap 
> area) suspends the applications, while a Major GC does.

Not true; a minor GC does suspend the mutator threads, just not for very long.  Even when
using concurrent mark-sweep, the app's threads are stopped, but just for very, very brief
periods.

> 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".

The sample traces do not show that occurring.

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

And by specifying fixed sizes for generations, you can upset the balance between old and new,
and prevent the GC logic from adjusting the ratios for the current workload characteristics.

> 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".

This part is true.

Given the relatively short duration of the minor GC operations relative to the observed response
time, I suspect that something else is going on during the period that may be causing a spike
in heap usage and the slowdown - but that can't be proven without more data about exactly
what's going on.  Looking at the heap usage visually will help: are you seeing a regular sawtooth
pattern, or does heap usage remain fairly flat and then suddenly spike?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus
for use only by the intended recipient. If you received this in error, please contact the
sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message