Re: [Resin-interest] Out of PermGen space
If it is not a leak (classes are being cleaned up upon webapp reload but a large number is being created), simply increase max perm size. Bill On Wed, Apr 25, 2012 at 11:47 PM, Matt White mwh...@leporidae.net wrote: On 4/24/2012 5:13 PM, Bill Au wrote: Wow, something I'm actually qualified to talk about on this list! :) Out of PermGen space is almost always caused by a classloader leak which occurs when a webapp is reloaded. It could be caused by either your own code, third-party code, or in some case Java core classes. I debug PermGen errors quite a bit. Some of our apps have a cache of dynamically generated classes (Drools does this) that, if held onto long enough, will make the the JVM run out of PermGen. This isn't really a mistake, it's just how it works, sadly. You need to take heap dumps before and after webapp reload and use a heap analyzer to see what is holding onto the leaked classloader(s). That's how I debug them. Take a series of heap dumps and start comparing the differences between them -- YourKit even makes this easy for you with a tool that diffs heap dumps. - Matt ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
On 04/25/2012 08:47 PM, Matt White wrote: On 4/24/2012 5:13 PM, Bill Au wrote: Wow, something I'm actually qualified to talk about on this list! :) Out of PermGen space is almost always caused by a classloader leak which occurs when a webapp is reloaded. It could be caused by either your own code, third-party code, or in some case Java core classes. I debug PermGen errors quite a bit. Some of our apps have a cache of dynamically generated classes (Drools does this) that, if held onto long enough, will make the the JVM run out of PermGen. This isn't really a mistake, it's just how it works, sadly. You need to take heap dumps before and after webapp reload and use a heap analyzer to see what is holding onto the leaked classloader(s). That's how I debug them. Take a series of heap dumps and start comparing the differences between them -- YourKit even makes this easy for you with a tool that diffs heap dumps. If you're using Resin 4.0, have you tried looking for the ZombieClassLoaderMarker? It's designed to make that tracing easier. -- Scott - Matt ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
