Tomcat on production server, PermGen and redeploys

问题:

It looks like

 MemoryError: PermGen space
 java.lang.OutOfMemoryError: PermGen space

is a common problem. You can Increase the size of your perm space, but after 100 or 200 redeploys it will be full. Tracking ClassLoader memory leaks is nearly impossible.

What are your methods for Tomcat (or another simple servlet container - Jetty?) on production server? Is server restart after each deploy a solution?

Do you use one Tomcat for many applications ?

Maybe I should use many Jetty servers on different ports (or an embedded Jetty) and do undeploy/restart/deploy each time ?

回答1:

I gave up on using the tomcat manager and now always shutdown tomcat to redeploy.

We run two tomcats on the same server and use apache webserver with mod_proxy_ajp so users can access both apps via the same port 80. This is nice also because the users see the apache Service Unavailable page when the tomcat is down.

回答2:

You can try adding these Java options:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

This enables garbage collection in PermGen space (off by default) and allows the GC to unload classes. In addition you should use the -XX:PermSize=64m -XX:MaxPermSize=128m mentioned elsewhere to increase the amount of PermGen available.

回答3:

Yes indeed, this is a problem. We're running three web apps on a Tomcat server: No. 1 uses a web application framework, Hibernate and many other JARs, no. 2 uses Hibernate and a few JARs and no. 3 is basically a very simple JSP application.

When we deploy no. 1, we always restart Tomcat. Otherwise a PermGen space error will soon bite us. No. 2 can sometimes be deployed without problem, but since it often changes when no. 1 does as well, a restart is scheduled anyway. No. 3 poses no problem at all and can be deployed as often as needed without problem.

So, yes, we usually restart Tomcat. But we're also looking forward to Tomcat 7, which is supposed to handle many memory / class loader problems that are burried into different third-party JARs and frameworks.

回答4:

PermGen switches in HotSpot only delay the problem, and eventually you will get the OutOfMemoryError anyway.

We have had this problem a long time, and the only solution I've found so far is to use JRockit instead. It doesn't have a PermGen, so the problem just disappears. We are evaluating it on our test servers now, and we haven't had one PermGen issue since the switch. I also tried redeploying more than 20 times on my local machine with an app that gets this error on first redeploy, and everything chugged along beautifully.

JRockit is meant to be integrated into OpenJDK, so maybe this problem will go away for stock Java too in the future.

http://www.oracle.com/technetwork/middleware/jrockit/overview/index.html

And it's free, under the same license as HotSpot:

https://blogs.oracle.com/henrik/entry/jrockit_is_now_free_and

回答5:

You should enable PermGen garbage collection. By default Hotspot VM does NOT collect PermGen garbage, which means all loaded class files remain in memory forever. Every new deployment loads a new set of class files which means you eventually run out of PermGen space.

回答6:

Which version of Tomcat are you using? Tomcat 7 and 6.0.30 have many features to avoid these leaks, or at least warn you about their cause.

This presentation by Mark Thomas of SpringSource (and longtime Tomcat committer) on this subject is very interesting.

回答7:

Just of reference, there is a new version of Plumbr tool, that can monitor and detect Permanent Generation leaks as well.