First of all, thanks for the analysis.
Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Java +GC question
java version "1.6.0_26"
Do we need to tell you to upgrade?
Whatever happened to the "Never change a running system" ?
Seriously, that system is not giving us any real concern, and it serves many customers on
different timezones.
Upgrading Java would mean having to plan long in advance with all of them some
simultaneous downtime, finding a Java 1.7 package that fits the OS level, and so on..
(pre-packaged things are sweet from a sysadmin point-of-view).
Rather than changing that one, we are setting up a new up-to-date machine, and migrating
customers one by one to the new one.
to a Java expert eye, does the following GC trace look "normal" , or
"pathological", or in-between ?
It's a little odd in that there are very few minor GCs occurring. This would
imply that whatever objects the application creates are either quite large (and
do not fit in the Eden space) or do not escape the methods that use them and
are thus allocated on the stack rather than the heap.
(I'll not even pretend to understand that)
Since the full GCs are 15 minutes apart, take little time, and the heap usage isn't
growing, I don't think there's anything to be concerned about.
Basically, my question was aimed at finding out if the way it was doing GC's implied that
we could gain some performance by increasing the Heap, or re-allocating/distributing some
parts of it. I gather from your response : "better leave it alone". Is that a correct
interpretation in light of what I was mentioning earlier ?
how does one interpret the leading timestamp ? seconds.milliseconds
since JVM start ?
Yes.
Any known (built-in) way of changing this to be real date/time timestamps, or
add such ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
