I'm running jboss 4.2.0 on Red Hat EL, and I'm getting this "java.lang.OutOfMemoryError: PermGen space" error. When I have a look at the log, the default for JAVA_OPTS is -Xms128m -Xmx512m, even though I could not find it set anywhere in run.sh (I can, though, find it in run.bat). I'm planning to increase the maximum memory size to 1024: -Xmx1024m by adding: JAVA_OPTS="-Xms128m -Xmx1024m $JAVA_OPTS"
My questions are: 1. Is it possible to increase the maximum size of the memory? 2. Why is this option not in run.sh but it is in run.bat?
1. Is it possible to increase the maximum size of the memory?
Yes, its possible. You can add your heap settings to the run.sh file (for JAVA_OPTS) similar to what you see in the run.bat file. You will have to decide what values are appropriate for your application.
Thanks for you answer for my first question. I've got the answer to question 2. It is actuallly in run.conf file for Linux/Unix. The problem that I'm having is actually the PermGen space, not the Heap Space. I increased the PermGen space and it is now working fine so far (fingers crossed). [ July 23, 2007: Message edited by: Ruby Martinus ]
The defaut PermGen space in Jave is 64MB, and you want to define a larger one.
To do so you need to set the two params -XX:PermSize=128m and -XX:MaxPermSize=128m in the JAVA_OPTS - the size is here set to 128MB - but you can set it to your own, it have to be below the max of -Xmx
The "PermGen" error happens, when the Java virtual machine runs out of memory in the permanent generation. Recall that Java has a generational garbage collector, with four generations: eden, young, old and permanent.
In the eden generation, objects are very short lived and garbage collection is swift and often.
The young generation consists of objects that survived the eden generation (or was pushed down to young because the eden generation was full at the time of allocation), garbage collection in the young generation is less frequent but still happens at quite regular intervals (provided that your application actually does something and allocates objects every now and then).
The old generation, well, you figured it. It contains objects that survived the young generation, or have been pushed down, and garbage collection is even less infrequent but can still happen.
And finally, the permanent generation. This is for objects that the virtual machine has decided to endorse with eternal life - which is precicely the core of the problem. Objects in the permanent generation are never garbage collected; that is, under normal circumstances when the jvm is started with normal command line parameters.
So what happens when you redeploy your web application is, that your WAR file is unpacked and its class files loaded into the jvm. And here's the thing: almost always ends up in the permanent generation...
(taken from: http://rlogiacco.blogspot.com/2009/02/jboss-and-permgen-outofmemoryerror.html)
Here are some advices I saw:
use this parameters for your JVM. they tell the Garbage Collector to invoke its algorithm also on the PermGen.
set JAVA_OPTS=-Xms512m -Xmx512m
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
The CMSPermGenSweepingEnabled setting includes the PermGen in a garbage collection run. By default, the PermGen space is never included in garbage collection (and thus grows without bounds).
The CMSClassUnloadingEnabled setting tells the PermGen garbage collection sweep to take action on class objects. By default, class objects get an exemption, even when the PermGen space is being visited during a garabage collection.
(taken from: http://community.eapps.com/showthread.php?p=537)
Restart your JBOSS because each time you deploy application, you increase the amount of data in the PermGen.
Use JRocket JVM instead of the Sun JVM. it doesn't have any PermGen in its Garbage Collector algorithm.
I would never use the CMS collector with less than 1GB of heap space. And I would not use the CMS collector unless I understood what effect it had on my application and system in general. Never ever ever use the CMS collector on a single CPU system. I would not turn it on unless I had at least 4 CPUs.
Do not rely on any undocumented options - their availability and behavior change from version to version. Stick to the options available here:
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp unless you want to get the source for the JVM you are using and looking up the current usage. For example, in JVM 6 the -XX:+CMSPermGenSweepingEnabled option results in a warning to use -XX:+CMSClassUnloadingEnabled instead.
Also, the statement that the GC ignores the permgen is not entirely true - if you turn on one of the GC monitoring options (PrintHeapAtGC, I think), you will often see the collector releasing classes from the permgen. OK, in the source I see this comment:
So turning on the CMS collector turns off permgen cleaning unless you turn that cleaning back on.
If you have done all that and still get this error, I have 1 more advise: Make sure you change the JAVA_OPT value only after JBOSS initializes it! otherwise, JBOSS would skip its initialization.
To my opinion, the best place to do that is at the end of the following file:
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop