“java.lang.OutOfMemoryError: PermGen space” in JBoss
Posted by Yannis Lionis on 01 Jun 2007 at 04:56 pm | Tagged as: Software
Oh this blasted error. How many times I’ve seen it in JBoss console. How many restarts because of it.
This has been a nuisance for quite a while. Basically what happens is that every time you (re)deploy an application to JBoss, the java process takes up a bit more memory, until after enough redeployments it runs out.
This blog gives a very good explanation of what the PermGen memory error is, how to monitor it and how to modify how much is available for your application.
This however did not solve the problem, as increasing the available PermGen space simply delayed the inevitable. The memory used by JBoss only goes up after each redeployment, so the painful end is unavoidable.
After chasing around the truth in various forums and blogs, each one suggesting a different culprit for the problem (Tomcat, cglib library, the combination of the two, Hibernate, and more) a colleague got a chance at a conference to ask some JBoss guys themselves for an answer. And an answer we got indeed: This problem happens with the Sun JVM. Use another one and it will go away.
So I did. I tried JRockit. And it worked. The problem went away. That simple.
So if you have the same problem, give it a try. It worked for me and it made my day.
19 Responses to ““java.lang.OutOfMemoryError: PermGen space” in JBoss”
Leave a Reply
You must be logged in to post a comment.
JRockit doesn’t have generational garbage collection - in other words, it doesn’t have permanent generation space. Therefore, it can’t have PermGen errors. Ever.
You might also want to try updating to beanutils 1.8.0 it fixes redplyment leaks…
http://www.jboss.org/feeds/post/redeployment_leaks_fixed_on_apache_beanutils
JRockit … does that mean I need to switch from jBoss to BEA WebLogic Application server, or can I just install it?
Do I need to install it on the server that runs muy JVM or on the machine that loads the applications hosted by the JVM?
No need to switch to Weblogic. Just download JRockit, install it on the server that JBoss is running on, and modify the JBoss startup script to use that jre instead of the one you were using so far.
ok, thanks, will give it a try.
Yannis,
Thanks for this information. Is this absolutely true? Are you very sure that Sun JVM has such an issue? If so, could you point me to some documentation? I googled this issue with perm gen and Sun JVM but not many authentic results.
The reason I ask is because we are facing this problem at one of our clients, and we want to make a recommendation! At least your blog suggests a potential solution
I read my post again and realised I wasn’t very clear about what the issue is. What the JBoss guys said is that the combination of the way that class loading works in the Sun JVM and the way that JBoss handles class loading causes the problem. The thing is, JBoss believe that what they’re doing is right and that the Sun JVM should be modified. Sun believe that what they’re doing is right and that JBoss should be modified. So there is no issue logged anywhere, because neither of them believes they’re doing anything wrong that they should be fixing.
I’d say your options are the following:
* Restart JBoss every time you redeploy. This memory leak happens only after a certain number of redeploys, so if this is a production server and there is a scheduled downtime for every new release, you can just restart it in the process and be done with it.
* Try it with JRockit. Because it works differently, it doesn’t have a PermGen area, so it will never get this error (see comments above). By all means though, test that your application works on JRockit first!
I hope this helps!
We’ve been wrestling with this error for a few months, ever since developing with JBoss. We’ve tried upping the memory, but the problem comes back. It occurs after we’ve redeployed an app (maybe a dozen or so times).
Thanks for the great article.
Really it solves our biggest issue faced with JBoss.
Thanks a lot for your great article…
No need to install JRockit also. Another simple and permanent solution to avoid PermGen Error is to set the below options in the server startup (eg. run.bat for jboss)
-XX:+UseConcMarkSweepGC
-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
this can be set using:
set JAVA_OPTS=-Xms680m -Xmx680m -XX:PermSize=128m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
the heap size should be set according to availability of memory.
set JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
these information really worked thanks for this solution Raghav
Thanks. It’s helpful information.
Thanks Yannis, Raghav,
I had the same error, and tried the JAVA_OPTS params you has suggested. Unfortunately I then get this error on starting JBoss
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
Press any key to continue . . .
I am on a Win XP 32 machine, with 4 GB of RAM. Any suggestions ?
Thanks
NikhilR,
The error to me means that your machine didn’t have enough free memory available in order for JBoss to initialise with the given JVM memory options. That seems a bit unlikely on a 4GB RAM machine, but then again it depends on what other things were running at the time and how much memory was free. I suggest trying to lower the memory needed by JBoss progressively until you get something that works and closing most other applications on the machine to maximise available free memory.
Thanks, this information is really worked.
set JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
Thanks a ton
[…] found some great articles, but the comments left behind by this particular user nailed it (Raghav http://blog.yannis-lionis.gr/?p=8). There were even some silly suggestions like switching to JRockit. Well ignore […]
This is mainly due to small size of permanent generation of heap.just increase size by using JVM option -XX:MaxPermSize=256m” as shown here
Anonymous,
That will only postpone the problem. Because the memory is never released, eventually you will still hit the problem.
The solution proposed by Raghav in the comments is the easiest solution.
It really helped me.
Thanks a lot!