Re: Urgent: PermGen memory leak in a NetBeans developed tomcat application
Tomi, Increasing Perm Gen size is normal, as long as it goes down again when it reaches the max and gets collected. The max depends on jvm version, possibly on server type and of course your startup options. 64MB default is not uncommon. You can watch it with -verbose:gc -XX:+printGCDetails. When it reaches the max, perm GC tries to collect unused classes. If it reclaims enough memory and this results in a stable process this is OK. You only have a problem, it the memory after collection is not stable. In some cases (eg. many, many JSPs you might need to increase perm gen. The classes listed below are dynamically generated by the Java reflection API and are the best candidates for getting collected, once your perm gen gets filled. Regards, Rainer Tomi N/A wrote: I've read a number of reports about similar problems, but can't distinguish which ones are relevant. My problem is that my available PermGen memory is constantly decreasing as the application works. I see this in the tomcat logs: ... [Loaded sun.reflect.GeneratedMethodAccessor197 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor198 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor199 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor200 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor201 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor202 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor203 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor204 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor205 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor206 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor207 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor208 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor209 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor210 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor211 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor212 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor213 from __JVM_DefineClass__] [Loaded sun.reflect.GeneratedMethodAccessor214 from __JVM_DefineClass__] ... I have no idea what these accessors are or how to stop their constant proliferation. Any suggestions would be very welcome. TIA, t.n.a. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Urgent: PermGen memory leak in a NetBeans developed tomcat application
From: Tomi N/A [mailto:[EMAIL PROTECTED] Subject: Urgent: PermGen memory leak in a NetBeans developed tomcat application [Loaded sun.reflect.GeneratedMethodAccessor197 from __JVM_DefineClass__] I have no idea what these accessors are or how to stop their constant proliferation. That's normal behavior when reflection is used. When the next full GC occurs, the accessor classes will be discarded, unless you have inhibited class unloading. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Urgent: PermGen memory leak in a NetBeans developed tomcat application
2007/5/16, Caldarale, Charles R [EMAIL PROTECTED]: That's normal behavior when reflection is used. When the next full GC occurs, the accessor classes will be discarded, unless you have inhibited class unloading. How do allow class unloading? How do I inhibit it, for that matter? t.n.a. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Urgent: PermGen memory leak in a NetBeans developed tomcat application
2007/5/16, Rainer Jung [EMAIL PROTECTED]: Tomi, Increasing Perm Gen size is normal, as long as it goes down again when it reaches the max and gets collected. The max depends on jvm version, possibly on server type and of course your startup options. 64MB default is not uncommon. I used JConsole just now and it seems stable...I'm bombarding tomcat with touch myapp/WEB-INF/web.xml every 10 seconds (to reload the app) and wget localhost:8080/myapp/faces/apage.jsp every 2 seconds. It seems stable here...but then again, it was never a problem on my devel machine: it's a problem at my hosting server. I don't even see any ...GeneratedMethodAccessor... lines in the logs here (well, not related to this problem, anyway). Thank you both for the quick reply: I'd appreciate further ideas if there are some. Cheers, t.n.a. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Urgent: PermGen memory leak in a NetBeans developed tomcat application
From: Tomi N/A [mailto:[EMAIL PROTECTED] Subject: Re: Urgent: PermGen memory leak in a NetBeans developed tomcat application How do allow class unloading? How do I inhibit it, for that matter? It's enabled by default (except for one of the esoteric garbage collectors). The -Xnoclassgc command line parameter inhibits class unloading. The papers linked to from the following page contain useful descriptions of GC behavior and options (although not much discussion of PermGen GC in any detail): http://java.sun.com/javase/technologies/hotspot/gc/index.jsp - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Urgent: PermGen memory leak in a NetBeans developed tomcat application
From: Paulo Alvim [mailto:[EMAIL PROTECTED] Subject: RES: Urgent: PermGen memory leak in a NetBeans developed tomcat application We've this classic problem (using Tomcat 5.x) with PermGen but in our case the leak occurs after a hot redeploy of any application. There are a couple of common causes for this, plus numerous more unusual ones. The two common ones are a shared library class keeping a reference to a webapp class or object, and injudicious use of ThreadLocal. More discussion here: http://opensource.atlassian.com/confluence/spring/pages/viewpage.action? pageId=2669 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Urgent: PermGen memory leak in a NetBeans developed tomcat application
2007/5/16, Paulo Alvim [EMAIL PROTECTED]: Hi Tomi, We've this classic problem (using Tomcat 5.x) with PermGen but in our case the leak occurs after a hot redeploy of any application. After each restart (our typical WAR has 30MB and 150 JSPs), jConsole shows about 4MB of PermGen increased that's never collected. Our customers have to increase the max PermGen size and monitoring - after 20 or 30 hot deploys, restart the server. It's not a big problem but we're also interested in solving this issue to get real 24 x 7 with Tomcat. Please let us know if you have the same situation... I built tapestry applications with very similar behavior. What I'm experiencing today is a bit different: simply using the application is draining available PermGen memory: a much more acute problem. I'll publish my findings, but as it is, I have a really small application which is really important and really under deadlines so I'm inclined to rewrite it on tapestry instead of JSF and deploy it on the server like that. ...looking back at what I've just written, I can't believe that this is the state of the art technology in 2007. :-\ Cheers, t.n.a. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Urgent: PermGen memory leak in a NetBeans developed tomcat application
-Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 11:34 AM To: Tomcat Users List Subject: RE: Urgent: PermGen memory leak in a NetBeans developed tomcat application From: Paulo Alvim [mailto:[EMAIL PROTECTED] Subject: RES: Urgent: PermGen memory leak in a NetBeans developed tomcat application We've this classic problem (using Tomcat 5.x) with PermGen but in our case the leak occurs after a hot redeploy of any application. There are a couple of common causes for this, plus numerous more unusual ones. The two common ones are a shared library class keeping a reference to a webapp class or object, and injudicious use of ThreadLocal. More discussion here: http://opensource.atlassian.com/confluence/spring/pages/viewpage.action? pageId=2669 There is also this http://mail-archives.apache.org/mod_mbox/tomcat-users/200602.mbox/%3C00ad01c [EMAIL PROTECTED] as a possible aggravating factor. Tim - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
