On 1/3/11 1:10 PM, Leon Rosenberg wrote: > Hello André, > > On Mon, Jan 3, 2011 at 1:35 PM, André Warnier <a...@ice-sa.com> wrote: >> Leon Rosenberg wrote: >>> 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 : >> http://chaoticjava.com/posts/how-does-garbage-collection-work/ >> >> 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. > > Nope. I mean we know that we have pauses (70 seconds) when the major > gc occurs, and we know, where it comes from, and we are fighting it, > but this is not the symptom ;-) > > >> >> 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". > > Actually no, in my understanding both are independent. I mean the gc > doesn't start "to copy over" if young is full, it simply cleans young. > However, > to quote your article: "Old generation objects are objects that > survived a few collections in the young generation area", and if > objects managed to survive longer as they should in the young space, > they might have been copied to old gen, despite the fact, that they > are young generation objects by nature (meaning short lifetime). This > theory is what I'm trying to check.
Objects which survive collections in young generations will make their way into the old generation, and then sit around for a long time waiting to be collected. What are your memory settings currently and how are the generations divided? How many processors do you have available and are you using CMS & incremental mode? p >> 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). > > No we can't, because it would also increase the time for full gc, > which will stop the application for even longer (causing enough > headache already :-() > > but anyway thanks for the suggestions ;-) > > regards > Leon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
