tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Armstrong <donaldjarmstr...@gmail.com>
Subject Re: JreMemoryLeakPreventionListener and hourly Full GC
Date Thu, 12 Aug 2010 21:04:43 GMT
Thank you Konstantin and Chris for your attention.

As stated in the initial post:
'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.'

Using the default JreMemoryLeakPreventionListener configuration that
has 'gcDaemonProtection=true'  will result in 1hr FullGCs using Sun
1.6 b18, b20 and b21on Solaris and Windows. We've tested and
successfully 'contained' the FullGC behavior using one of the below
configurations:

1) suppress the FullGC using JVM arg -XX:+DisableExplicitGC

2) keep the FullGC but to defer to the CMS collector using JVM arg
-XX:+ExplicitGCInvokesConcurrent

3) <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
gcDaemonProtection="false"/>

4) Disable the listener altogether


We've decided to go with option 3.

Thanks,
Donnie


On Thu, Aug 12, 2010 at 9:15 AM, Christopher Schultz
<chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Konstantin,
>
> On 8/12/2010 7:48 AM, Konstantin Kolinko wrote:
>> It looks that with your version of JRE and with your setting it is
>> better to run with gcDaemonProtection="false".  I certainly do not
>> know how other JRE versions behave here. (Feedback is welcomed).
>
> That's what he's got, now: gcDaemonProtection="false" (see the OP), but
> the GC is still happening.
>
> Donald, the reason the JreMemoryLeakPreventionListener makes the call to
> GC.requestLatency is to un-do the effect of some other component (RMI,
> it seems).
>
> It's possible that some component other than the
> JreMemoryLeakPreventionListener is causing the periodic full GC.
>
> Try disabling the listener altogether and see if the GCs go away.
>
> If they don't, consider recompiling the JreMemoryLeakPreventionListener
> with some debugging code in there (the current code does not emit any
> logging unless there is a problem calling GC.requestLatency... it does
> not announce it's intention of doing so, even at a TRACE level).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxkAfAACgkQ9CaO5/Lv0PBgjACgkeQyW4H949HJ/k+28hjKR3JH
> 9tsAoLIxzWfypWAhR9PzC4IQpGFF0Kwy
> =5GDP
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message