Recently I ran into this error in my web application:
java.lang.OutOfMemoryError: PermGen space
It's a typical Hibernate/JPA + IceFaces/JSF application running on Tomcat 6 and JDK 1.6.
Apparently this can occur after redeploying an application a few times.
The solution was to add these flags to JVM command line when Tomcat is started:
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
You can do that by shutting down the tomcat service, then going into the Tomcat/bin directory and running tomcat6w.exe. Under the "Java" tab, add the arguments to the "Java Options" box. Click "OK" and then restart the service.
Source: orx's comment on Eric's Agile Answers.
Alternatively, you can switch to JRockit which handling permgen differently then sun's jvm. It generally has better performance as well.
JRockit resolved this for me as well; however, I noticed that servlet restart times were much worse, so while it was better in production, it was kind of a drag in developemnt.
use the command line parameter -XX:MaxPermGen=128m for a Sun JVM. (obviously substituting 128 for whatever size you need)
I still keep getting the error despite trying the
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
I have also tried
-XX:MaxPermGen=128m
Nothing seems to work on my Sun JDK 1.6.0_12, Any clue? Should move to Jrockit JVM
The configuration of the memory depends on the nature of your app.
What are you doing?
What's the amount of transactions precessed?
How much data are you loading?
etc.
etc.
etc
Probably you could profile your app and start cleaning up some modules from your app.
Apparently this can occur after redeploying an application a few times
Tomcat has hot deploy but it consumes memory. Try restarting your container once in a while. Also you will need to know the amount of memory needed to run in production mode, this seems a good time for that research.
You better try -XX:MaxPermSize=128M rather than -XX:MaxPermGen=128M.
I can not tell the precise use of this memory pool, but it have to do with the number of classes loaded into the JVM. (Thus enabling class unloading for tomcat can resolve the problem.) If your applications generates and compiles classes on the run it is more likely to need a memory pool bigger than the default.
I have fought this for hours, but I have no good news.
See my related question: http://stackoverflow.com/questions/1996088/java-class-permgen-memory-leak-web-applications-generic-solution
You may still have a memory leak, e.g. classes are not garbage collected because your WebAppClassLoader is not garbage collected (it has an external reference that is not cleared). increasing the PermGen will only delay the OutOfMemoryError, and allowing class garbage collection is a precondition, but will not garbage collect classes if their class loader still has references to it.
set -XX:PermSize=64m -XX:MaxPermSize=128m Later on you may also try increasing MaxPermSize. Hope it'll work. The same work for me. Setting only MaxPermSize didn't worked for me.
They Say that the latest rev of Tomcat (6.0.28 or 6.0.29) handles the task of redeploying servlets much better.
"They" are wrong because I'm running 6.0.29 and have the same problem even after setting all of the options. As Tim Howland said above, these options only put off the inevitable. They allow me to redeploy 3 times before hitting the error instead of every time I redeploy.