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 :
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.
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
