|Donald Armstrong||Aug 11, 2010 9:14 am|
|Christopher Schultz||Aug 11, 2010 10:33 am|
|Donald Armstrong||Aug 11, 2010 5:05 pm|
|Konstantin Kolinko||Aug 12, 2010 4:47 am|
|Christopher Schultz||Aug 12, 2010 7:14 am|
|Donald Armstrong||Aug 12, 2010 2:04 pm|
|Christopher Schultz||Aug 13, 2010 1:02 pm|
|dona...@gmail.com||Aug 13, 2010 1:39 pm|
|Subject:||Re: JreMemoryLeakPreventionListener and hourly Full GC|
|From:||Donald Armstrong (dona...@gmail.com)|
|Date:||Aug 12, 2010 2:04:20 pm|
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
4) Disable the listener altogether
We've decided to go with option 3.
On Thu, Aug 12, 2010 at 9:15 AM, Christopher Schultz <chr...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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-----