Comments on: PermGen Nightmares

By: Odi

Odi — Wed, 20 Jun 2007 22:04:49 +0000

Nuno, these options are only effective if you have enabled the *concurrent* mark and sweep GC (CMS) with -XX:+UseConcMarkSweepGC.

By: Joe

Joe — Wed, 20 Jun 2007 20:12:47 +0000

Specifically with JDBC (since it’s often the most common problem) - move any JDBC drivers in your webapps lib into Tomcat’s common/lib folder instead.

This solved nearly all my (web) PermGen problems in one go …

By: Odi

Odi — Wed, 20 Jun 2007 15:31:44 +0000

Use JConsole to analyze if you have sized the memory pools according to your app needs. No need for a big heap if all you lack is PermGen. You may want to tune PermGen and CodeCache (that’s for classes compiled by HotSpot): -XX:MaxPermSize=256m -XX:ReservedCodeCacheSize=64m

However, crashes due to PermGen OOM indicates a memory leak with class loading. Especially when redeploying WARs, the chances for class leaks are very big. If anything still has a reference to an object of your webapp, that effectively prevents unloading of its classloader and so all classes in the WAR. Common leaks are DB driver registrations with the JDBC driver manager, Swing listeners, SoftReferences, Objects in JNDI, RMI, unterminated threads, Logger instances, JMX beans, open sockets, open files. Use a heap analyzer (jmap / jhat) to find the dangling references.

But the PermGen inventors are not to blame. It’s YOU not cleaning up properly.

By: Nuno Sousa

Nuno Sousa — Wed, 20 Jun 2007 12:48:00 +0000

Hi.

If you are using Sun’s JVM, Garbage Collection for the Permanent Generation is switched off by default. Since you are using Tomcat and redeploying WAR files, tomcat also creates new class loaders, so it is a good thing to enable Class Unloading in the VM also — this to is switched off by default.

In summary: add these options to the java command

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Have fun,
Nuno