Thanks for your attention chris,
We've identified why every hour: sun.misc.GC.requestLatency(3600000l)
I was able to confirm with the tomcat documentation that with
gcDaemonProtection enabled, the "GC Daemon" thread is running.
We've identified why the Full GC; I've looked at the decompiled code
for the sun.misc.GC class and there is a System.gc() call buried in
there. It is hard to read, but likely here the Full GC is happening.
{
synchronized(GC.lock)
{
l = GC.latencyTarget;
if(l != 9223372036854775807L)
break label0;
GC.daemon = null;
}
return;
}
long l1 = GC.maxObjectInspectionAge();
if(l1 >= l)
{
System.gc();
l1 = 0L;
}
The documentation does not indicate if the
JreMemoryLeakPreventionListener should be enabled for production
environments, but based on this information, probably not?
Thank you for your opinion.
Donnie
On Wed, Aug 11, 2010 at 12:34 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Donald,
>
> On 8/11/2010 12:15 PM, Donald Armstrong wrote:
>> We have recently deployed tomcat-6.0.28 in our organization and are
>> noticing every hour, a Full GC is occurring. The same application,
>> same JVM, same JVM args, just a new tomcat release.
>>
>> I have addressed the issue by adjusting the server.xml and disabling
>> gcDaemonProtection.
>
> Why?
>
>> Ideas on what is causing the Full GC and why every hour?
>
> There is no javadoc for this class which is unfortunate, but the
> documentation in
> http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html is likely
> where you found this configuration option.
>
> Here's what it says about gcDaemonProtection:
>
> "
> Enables protection so that calls to sun.misc.GC.requestLatency(long)
> triggered by a web application do not result in a memory leak. Use of
> RMI is likely to trigger a call to this method. A side effect of
> enabling this protection is the creation of a thread named "GC Daemon".
> The protection is uses reflection to access internal Sun classes and may
> generate errors on startup on non-Sun JVMs. The default is true.
> "
>
> Looking at the code for JreMemoryLeakPreventionListener, no threads are
> fired from that code. The code in there calls the static method
> sun.misc.GC.requestLatency(3600000l) - that's one hour, if the argument
> is in ms. I'm having trouble following the decompiled code, but I can't
> find anywhere that a Thread is actually started.
>
> Have you tried to take a thread dump to see what threads are running?
> Presumably, you ought to see something interesting in there. Are you
> able to run a profiler against the process to see where the thread is
> created?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxi3w4ACgkQ9CaO5/Lv0PAYBQCfe7+POwLPcW6p9QQyWlLbSspZ
> Z+EAn1H1FrU2QQ40fUiywug7Ohz2fpP7
> =GC7n
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
