We have a PermGen Out of memory exception in our J2EE web application:
java.lang.OutOfMemoryError: PermGen space
We have read so many posts about how to solve it and almost all of them say that we have to increase PermSize (default and maximum). But we are not able to change them. We have tried to modify setenv.sh, catalina.sh and startup.sh adding this code:
But when we check it using "jstat -gcpermcapacity " nothing changes; the memory is always the same. Our enviroment is Centos 6, Apache 2.2, Tomcat 5.5, Java 6 and we have done our app deploy installing servlets by WHM in our account.
How can I check if this configuration is being applied? Is there any command to know how much PermGen memory is the maximum? We have tried "ps ax | grep tomcat" and "jstat -gcpermcapacity <PID>". The last one allways shows the same value for PGCMX(maximum memory): 83968.0, so we think that none of our configurations have been succesful.
Our server run Tomcat through WHM and cPanel. We use an account function to install servlets and when we change something in our webapp we use the "restart Tomcat" option in WHM (which is a webhost manager, a cPanel's layer), so we don't know the exactly script which run Tomcat, that's the reason (we think) becouse our attempts failed.
Actually, the way I knew it worked was that Tomcat stopped throwing PermGenSpace errors!
I noticed that you were attempting to set PermGenSpace to a very large value. PermGenSpace is a separate memory space from Heap/Stack space and it doesn't need to be that large. Just larger than the default in cases like ours. I was using memory-statistics to determine requirements:
ps shows the memory usage for the entire VM, of which PermGenSpace is just a subset. I can't vouch for what WHM does, although hopefully it isn't so far off-track that it doesn't honor setenv.sh. If you can, try jprofiler. I believe that it can display PermGenSpace in real time graphically.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
¡We have solved the problem!
Our application runs on WHM, and the script that runs the restart of Tomcat does not use the startup.sh file. In our case, the reset is performed by "starttomcat", a file found in /usr/bin. We have modified the file, leaving the variable my @ cmd as follows: