java.lang.OutOfMemoryError: PermGen space

Posted on 26 aprile 2011 di

0


1. Descrizione Problema

Periodicamente il webserver risulta inaccessibile

2. Cause

La causa è palesata dal log di catalina (vedi grassetto)

catalina.out

Exception in thread “servername_127.0.1.1_/opt/tomcat/work/Catalina/localhost/nomeapplicazione” java.lang.OutOfMemoryError: PermGen space


Exception in thread “http-80-42” java.lang.OutOfMemoryError: PermGen space

Apr 20, 2011 4:32:51 PM org.apache.coyote.http11.Http11Processor process

SEVERE: Error processing request

java.lang.OutOfMemoryError: PermGen space

[GarbageCollectorProcess][20/04/2011 – 16:33:56] CREATE!

[GarbageCollectorProcess][20/04/2011 – 16:35:55] (new free memory in step n. ‘1’of 1 = 1Kb)

[GarbageCollectorProcess][20/04/2011 – 16:35:55] (new free memory / actual free memory / allocated memory) – (1Kb / 3.871.790Kb / 4.142.977Kb)

[GarbageCollectorProcess][20/04/2011 – 16:35:55] DISPOSE!

PermGen space

java.lang.OutOfMemoryError: PermGen space

Exception in thread “http-80-11” java.lang.OutOfMemoryError: PermGen space

[GarbageCollectorProcess][20/04/2011 – 16:44:15] CREATE!

Exception in thread “ContainerBackgroundProcessor[StandardEngine[Catalina]]” java.lang.OutOfMemoryError: PermGen space

Il tutto è sempre generato da una applicazione.

3. Motivo

The problem is that Tomcat does not garbage collect the Classloader and the classes it loads. Each you reload the webapp context, more copies of these classes are loaded, and as these are stored in the permanent heap generation, it will eventually run out of memory.

The same issue could affect (and affects) to any container. You just have to restart the container instead of restarting the context.

It’s easy to reproduce this problem by reloading the context over and over again until you get an OutOfMemoryError (10 times was enough for a simple app)

4. Attuale configurazione

root@servername:~# ps -ef | grep java

root      1034     1  5 Apr20 ?        00:57:59 /opt/java/bin/java -server -Xmx4096m -Xms4096m -XX:MaxPermSize=256m -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+UseParallelOldGC -XX:+AggressiveHeap -XX:+UseCompressedOops -Dfile.encoding=ISO-8859-15 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1234 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties -Djava.endorsed.dirs=/opt/tomcat/endorsed -classpath :/opt/tomcat/bin/bootstrap.jar -Dcatalina.base=/opt/tomcat -Dcatalina.home=/opt/tomcat -Djava.io.tmpdir=/opt/tomcat/temp org.apache.catalina.startup.Bootstrap start

5. Possibile Soluzione

 

The -XX:+CMSPermGenSweepingEnabled flag is often used to mitigate against PermGen OutOfMemory errors, however I have read elsewhere that people have found that by following the above advice they have still had these errors, but by sticking with -XX:+CMSPermGenSweepingEnabledas well as -XX:+CMSClassUnloadingEnabled their VM has stayed up longer between restarts.

Does -XX:+CMSClassUnloadingEnabled really supersede -XX:+CMSPermGenSweepingEnabled or is there still some benefit in having them both?

Thanks in advance

Rich ps: I know that the root cause of perm gen issues is still usually Classloader leaks, this is more about the message that the JVM produces if we use the above options.

Approfondimenti:

http://jroller.com/agileanswers/entry/preventing_java_s_java_lang

http://stackoverflow.com/questions/3717937/cmspermgensweepingenabled-vs-cmsclassunloadingenabled

Annunci
Posted in: Java