[from your blog entry] > I also think that logging leaks may be more helpful than using part of > manager, because many don't deploy manager (they remove it). it is logged when the application is stopped, on recent tomcat 6 and 7.
I think your approach to finding leaks by performing comparisons is not the most efficient. What I usually do to find the leak is to use MAT (eclipse memory analyzer, as you used too) and its "class loader explorer". There I find the instance of org.apache.catalina.loader.WebappClassLoader that corresponds to my webapp and right-click to ask "path to GC roots"/"exclude all phantom/weak/soft, etc. references". There I usually see the cause of the leak vey quickly. I you find no strong reference to your classloaders then you might have encountered some JDK bug... You should use a recent one to avoid some (at least 6.0u21). Sylvain On 10 mai 2011, at 21:55, Gary Weaver wrote: > Here's what I did and what little I came up with: > http://stufftohelpyouout.blogspot.com/2011/05/diagnosing-webappportlet-hot-deploy.html > > I'm definitely not an expert at diagnosing leaks, so if you have any > recommendations/comments, please let me know. > > I unfortunately started off just thinking I could tune JVM settings, not > just by bumping up permgen but by adding things like: > > -XX:+UseParNewGC > -XX:+UseConcMarkSweepGC > -XX:+CMSPermGenSweepingEnabled > -XX:+CMSClassUnloadingEnabled > > But, I was (really) wrong as you can see in the post, along with the various > tools used to try to identify what was causing the issue(s). > > It doesn't seem like determining exactly what is leaking memory (at least in > the case of permgen and hot-redeploys/hot-deploys) is a whole lot easier > than it was years ago, unless I'm doing something wrong, which I most likely > am. Thanks in advance for any feedback! > > Gary --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
