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