On 28.05.2010 16:26, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: tomcat memory question
Check may (will?) correct me on this
-1 for spelling
I believe a full GC might be necessary to clear-out certain
resources such as completed Threads or other things that have
concrete OS-level counterparts.
Not exactly; a full GC is necessary to clear out dead classes and any objects
that have migrated into the tenured generation. The OS-level thread structures
are gone as soon as the java.lang.Thread instance stops running (returns from
the run() method), while the Java instance will hang around as long as there
are references to it. Some OS resources will stay allocated until a GC happens
*if* the program fails to explicitly close them before the corresponding Java
object becomes unreachable (aka sloppy programming), but any kind of GC that
discovers such a dead object will release the associated native resources.
If you are using a lot of (non-pooled) threads or socket
connections, the JVM may be performing full GCs to clean
up those resources.
GC itself knows nothing about the relationship between Java objects and
external resources; only the finalizer for such a class does.
Frequent full GCs might just mean that you are using a lot of your
memory. As long as you don't get any OutOfMemoryErrors, it appears
that your heap is adequate for the load you're experiencing.
Assuming there are no memory leaks, it's an indication that the heap is
undersized for the application, or that the application is behaving in an
unexpected fashion with regard to expected object creation patterns. (An
application that creates only long-lived objects, for example - but that's
really hard to believe that could happen in a servlet container.)
There's a couple of options. We can't decide, because we only see
partial data (and none of GC logging, which is much more helpful when
enabled correctly):
- distributed GC because of RMI. That would fit the once per minute Full
GC. But the data presented looks like it's not once per minute, but
about once to twice per minute.
- full gc triggered by class unloading: but perm doesn't seem to be
close to some magic size.
- lots of allocation flooding the semi spaces and flowing over into tenured.
Did you give us only the jstat lines, which happened after the increase
of the FGC counter? The used capacity of tenured (OU/OC) seems to be
very small in all lines given, which would be normal and hide the GC
reason, if you had thrown away all data lines immediately before a FGC.
The same for Perm and class unloading.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
