Search code examples
linuxtomcatjvmtomcat6permgen

PermGen issues persisting even after Tomcat restart (Linux, Tomcat 6.0.35)


Tomcat has got that well-known memory leak problem that causes PermGen space errors after too much redeploying.

What I'd like to know is best practices to reload the server in a way that completely resets that space and erases existing memory leaks. Just using shutdown.sh and startup.sh isn't cutting it: it seems that leaked memory stays leaked. Rebooting the machine works of course, but I'd like to know if a quicker/cleaner/safer solution exists.

Thanks!

(I can allocate more PermGen space, of course, but that's just delaying the problem, and I'd like to flush away the leaked memory before I declare the apps as production-ready, since I'm changing jobs afterwards and thus the apps won't get redeployed for a while)

EDIT: as mentioned in the comments below, it seems the scripts are supposed to flush all memory already since they create a new JVM, so there must be some other factor causing PermGen errors to keep happening even in a new JVM, after many redeploys.


Solution

  • Tomcat does not have PermGen leaks, webapp redeploys or not. The problem is either with your webapp itself, a library you use, or, in some cases, the Java standard library implementation. All of these can be solved without resorting to throwing up your arms and blaming Tomcat.

    Try reading http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf to learn how to diagnose these leaks properly. Get yourself a profiler (this can even be done with freely-available utilities included in the JDK like JVisualVM).

    Tomcat 7 includes a memory leak prevention utility that can work-around problematic Java API implementations (e.g. AWT). Everything else is your problem or your libraries' problems. Most open-source libraries where such PermGen leaks have been found have quickly worked to patch their libraries in order to avoid them (or provide a graceful way for client code to avoid a PermGen leak).