I am getting this java.lang.OutOfMemoryError: PermGen space Exception. I am using Eclipse Juno and Tomcat 7.0. This Exception occurs at least once in every 10-15 Minutes in a console. How to resolve it?
Feb 25, 2016 10:23:23 AM org.springframework.beans.factory.support.DefaultListableBeanFactory destroyBean
SEVERE: Destroy method on bean with name 'mvcUrlPathHelper' threw an exception
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessBeforeDestruction(PersistenceAnnotationBeanPostProcessor.java:375)
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:242)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:578)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:554)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:925)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:523)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingletons(DefaultListableBeanFactory.java:932)
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:997)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:547)
Feb 25, 2016 10:23:24 AM org.springframework.beans.factory.support.DefaultListableBeanFactory destroyBean
SEVERE: Destroy method on bean with name 'mvcPathMatcher' threw an exception
java.lang.OutOfMemoryError: PermGen space
Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" java.lang.OutOfMemoryError: PermGen space
What is java.lang.OutOfMemoryError: PermGen space?
Ans:
The java.lang.OutOfMemoryError: PermGen space message indicates that the Permanent Generation’s area in memory is exhausted.
Any Java applications is allowed to use a limited amount of memory. The exact amount of memory your particular application can use is specified during application startup.
Java memory is separated into different regions which can be seen in the following image:
What will be the solution for this error PermGen space?
Ans:
For Heap,
export JVM_ARGS="-Xms1024m -Xmx1024m"
For Permgen,
JVM_ARGS="-XX:PermSize=512M -XX:MaxPermSize=512m"
You can give also additional section
-XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC XX:+CMSClassUnloadingEnabled
You can also give more additional section :)
-XX:PermSize=512m -XX:MaxPermSize=512m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -XX:SurvivorRatio=2 -XX:MaxTenuringThreshold=128 -XX:TargetSurvivorRatio=90 -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:+UseTLAB -XX:+CMSParallelRemarkEnabled -XX:+CMSClassUnloadingEnabled
Metaspace: A new memory space is born
The JDK 8 HotSpot JVM is now using native memory for the representation of class metadata and is called Metaspace; similar to the Oracle JRockit and IBM JVM's.
The good news is that it means no more java.lang.OutOfMemoryError: PermGen space problems and no need for you to tune and monitor this memory space anymore.
Related Link:
https://plumbr.eu/outofmemoryerror/java-heap-space
https://plumbr.eu/outofmemoryerror/permgen-space
http://stas-blogspot.blogspot.in/2011/07/most-complete-list-of-xx-options-for.html#UseConcMarkSweepGC
https://www.javacodegeeks.com/2013/12/decoding-java-lang-outofmemoryerror-permgen-space.html
http://www.javavillage.in/reasons-outofmemory-permespace.php
Dealing with "java.lang.OutOfMemoryError: PermGen space" error
Java 8 Links
What is the use of MetaSpace in Java 8?
https://blogs.oracle.com/poonam/entry/about_g1_garbage_collector_permanent
https://plumbr.eu/outofmemoryerror/metaspace
https://dzone.com/articles/java-8-permgen-metaspace
It is easy to configure Java for more PermGenSpace but I would recommend to migrate to Java 1.8 runtime instead. Install Java 8 SDK and add two lines like
-vm
D:/jdk8/jre/bin/javaw.exe
to eclipse.ini. This problem is fixed starting from Java 1.8 and does not longer require any hacks.
Instead making changes in eclipse.ini, its better to install Java 8.
I Installed Java 8 and now I am not getting java.lang.OutOfMemoryError: PermGen space Exception.
Related
In my application I'm creating lots of java classes at runtime with javassist library. At some point a java.lang.OutOfMemoryError: Metaspace is thrown but java process monitoring (based on java.lang.management.MemoryPoolMXBean) reports that there is plenty of free metaspace. Why is that? And how to use 100% of metaspace memory pool?
I've created a minimal application that reproduces the problem https://github.com/vlkv/java_metaspace_oom
Donwload it, cd to the project dir and then execute 'ant run'. In this app, I've set -XX:MaxMetaspaceSize=100m, but OOM is thrown at some point around 23564Kb of metaspace used.
Call stack of the error is:
javassist.CannotCompileException: by java.lang.OutOfMemoryError: Metaspace
at javassist.ClassPool.toClass(ClassPool.java:1170)
at javassist.CtClass.toClass(CtClass.java:1316)
at com.tradingview.Main.generateRandomClass(Main.java:53)
at com.tradingview.Main.main(Main.java:24)
Caused by: java.lang.OutOfMemoryError: Metaspace
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javassist.ClassPool.toClass2(ClassPool.java:1183)
at javassist.ClassPool.toClass(ClassPool.java:1164)
... 3 more
Wow, I've just found an answer.
The problem is that in my application I create a separate new ClassLoader for every generated Class. I've done a modification in my sample app that puts all the generated classes to one ClassLoader and after that, OOM is thrown at the point when free metaspace is almost zero. The fix is here https://github.com/vlkv/java_metaspace_oom/commit/d6bcade51f79758e2413d1852c771f163392c294 branch fix_of_the_problem
Does somebody knows about what are the limits for class loaders in java process? And how to increase them?
Also found this Why MetaSpace Size is twice as big as Used MetaSpace?
I am often getting this error when I restart my resin web server. How to avoid this error.
11:01:55.679] {resin-12} WebApp[production/webapp/default/app] fail
[15-11-24 11:01:55.681] {resin-95} java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
Try to increase value of variables
-Xms, -Xmx, -XX:PermSize, -XX:MaxPermSize in your apache configuration.
E.g. -Xms1024m -Xmx2048m -XX:PermSize=1024M -XX:MaxPermSize=2048M
I'm running a new Jeninks Master instance on Windows (windows server 2012).
The Jenkins master has failed twice in 5 days. the Jenkins instance has about 30 nodes and is not too busy.
I noticed the memory consumption of Jenkins was quite low (400mb) with the default java memory settings in jenkins.xml
I modified the jenkins.xml to -Xrs -Xmx1536m and the Java process is not using 515mb of memory.
I tried to set Xmx to a higher value but the Jenkins service would not start.
After the 2nd failure today, I got the same error message below repeated.
The windows server has 8 cores and 16GB memory. Average CPU is <5% and average memory usage is 2GB. Jenkins version is 1.609.3
Any help pointers appreciated....
Sep 21, 2015 12:00:48 PM org.eclipse.jetty.util.log.JavaUtilLog warn
WARNING:
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.addWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source)
at winstone.BoundedExecutorService.scheduleNext(BoundedExecutorService.java:74)
at winstone.BoundedExecutorService.execute(BoundedExecutorService.java:64)
at org.eclipse.jetty.util.thread.ExecutorThreadPool.dispatch(ExecutorThreadPool.java:126)
at org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager.dispatch(SelectChannelConnector.java:300)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.dispatch(SelectChannelEndPoint.java:236)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.schedule(SelectChannelEndPoint.java:195)
at org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:498)
at org.eclipse.jetty.io.nio.SelectorManager$1.run(SelectorManager.java:290)
at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Found a solution to this. I installed the JDK and used VisualVM to monitor the memory usage for JVM. This showed 32 bit memory boundaries. After a little digging the java.exe that Jenins points to by default in Jenkins_Home/jre/bin is a 32bit version of java. I modified the Jenkins.xml to point to the already installed 64 Jre. This worked fine and was able to modify the Xmx valve to 4G. Jenkins is now running happly using <2gb of memory for the JVM process.
This question already has answers here:
How to clear PermGen space Error in tomcat
(11 answers)
Closed 9 years ago.
I installed tomcat 7 to upgraded my JIRA projeect version from 5.0 to 6. After I place the project folder in tomcat's webapps. I run this localhost:8080/jira
after long time running, it throws some error message. Please help us to fix this problem thanks in advance
java.lang.RuntimeException: PermGen space
at com.atlassian.event.internal.SingleParameterMethodListenerInvoker.invoke(SingleParameterMethodListenerInvoker.java:54)
at com.atlassian.event.internal.AsynchronousAbleEventDispatcher$2.run(AsynchronousAbleEventDispatcher.java:66)
at com.atlassian.event.internal.AsynchronousAbleEventDispatcher$1.execute(AsynchronousAbleEventDispatcher.java:32)
at com.atlassian.event.internal.AsynchronousAbleEventDispatcher.dispatch(AsynchronousAbleEventDispatcher.java:60)
at com.atlassian.event.internal.EventPublisherImpl.invokeListeners(EventPublisherImpl.java:160)
at com.atlassian.event.internal.EventPublisherImpl.publish(EventPublisherImpl.java:79)
at com.atlassian.plugin.event.impl.DefaultPluginEventManager.broadcast(DefaultPluginEventManager.java:84)
at com.atlassian.plugin.manager.DefaultPluginManager.addPlugins(DefaultPluginManager.java:768)
at com.atlassian.plugin.manager.DefaultPluginManager.init(DefaultPluginManager.java:200)
at com.atlassian.jira.plugin.JiraPluginManager.start(JiraPluginManager.java:63)
at com.atlassian.jira.ComponentManager$PluginSystem.start(ComponentManager.java:635)
at com.atlassian.jira.ComponentManager.startJIRA(ComponentManager.java:214)
at com.atlassian.jira.ComponentManager.quickStart(ComponentManager.java:208)
at com.atlassian.jira.ComponentManager.start(ComponentManager.java:193)
at com.atlassian.jira.upgrade.PluginSystemLauncher.start(PluginSystemLauncher.java:23)
at com.atlassian.jira.startup.DefaultJiraLauncher$3.run(DefaultJiraLauncher.java:107)
at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrEnqueue(DatabaseConfigurationManagerImpl.java:323)
at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrWhenDatabaseActivated(DatabaseConfigurationManagerImpl.java:211)
at com.atlassian.jira.startup.DefaultJiraLauncher.postDbLaunch(DefaultJiraLauncher.java:100)
at com.atlassian.jira.startup.DefaultJiraLauncher.access$100(DefaultJiraLauncher.java:27)
at com.atlassian.jira.startup.DefaultJiraLauncher$1.run(DefaultJiraLauncher.java:66)
at com.atlassian.jira.util.devspeed.JiraDevSpeedTimer.run(JiraDevSpeedTimer.java:33)
at com.atlassian.jira.startup.DefaultJiraLauncher.start(DefaultJiraLauncher.java:61)
at com.atlassian.jira.startup.LauncherContextListener.contextInitialized(LauncherContextListener.java:54)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4797)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5291)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1637)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.OutOfMemoryError: PermGen space
More helpful solution is to increase values in JAVA_OPTS variable.
Add next line to your Catalina.bat/Catalina.sh file in bin directory
For Windows (Catalina.bat)
set JAVA_OPTS="-Xms1024m -Xmx10246m -XX:NewSize=256m -XX:MaxNewSize=356m -XX:PermSize=256m -XX:MaxPermSize=356m"
For Unix (Catalina.sh)
export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:NewSize=256m -XX:MaxNewSize=356m -XX:PermSize=256m -XX:MaxPermSize=356m"
More solutions you can find in this article
Sometimes after re-deployments the Garbage Collector can't destroy some objects on Tomcat and run out of space.
There are many reasons for these case:
If you use some CRUD-Objects - check if there are all closed after using.
If your app used other libs - sometimes the Objects from these libs cant also be destroyed, like MysqlConnector, Hibernate/C3p0 or other - try to put these libs on the tomcat/lib folder
Check the Tomcat with the "Java VisualVM" and check the permGen after re-deployment.
The default value for the permGen Space are often also very low you can increase them with the following javaVM parameter
-XX:PermSize=64M -XX:MaxPermSize=256m
You can follow these tutorial
http://www.mkyong.com/tomcat/tomcat-javalangoutofmemoryerror-permgen-space/
UPDATE
other solution maybe found here : what to do with tomcat PermGen space
add -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC to the javaVM options
Tweak the value of the permgen using -XX:PermSize={value} and -XX:MaxPermSize={value} via the JAVA_OPTS variable where 'value' is a string like 256m.
Recently I started getting PermGen space issue in my new jasper report application when tested under heavy load. I'm using groovy as expression evaluator for reports, by specifying language="groovy in my jrxml file. As groovy expressions, create classes at runtime, I'm suspecting this to be the root cause for permgen filling up. I tried up setting up jvm options like -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled , but it did not help in solving the problem. Even in excpetion stacktrace (given below) also, classloader is trying to load the newly built class into permgen at the time of failure. Has anyone experienced this problem using groovy with jasper reports? My reports get filled asynchronously in a separate thread using capabalities provided by AsynchronousFillHandle class provided by jasper. Does this have any connection towards the classloader not releasing the loaded runtime classes? Any suggestions would be greatly appreciated.
Exception in thread "Thread-563" java.lang.OutOfMemoryError: PermGen space
Exception in thread "Thread-565" at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts.define(ClassLoaderForClassArtifacts.java:42)
at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts$1.run(ClassLoaderForClassArtifacts.java:86)
at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts$1.run(ClassLoaderForClassArtifacts.java:84)
at java.security.AccessController.doPrivileged(Native Method)
at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts.defineClassAndGetConstructor(ClassLoaderForClassArtifacts.java:84)
at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compilePogoMethod(CallSiteGenerator.java:215)
at org.codehaus.groovy.reflection.CachedMethod.createPogoMetaMethodSite(CachedMethod.java:220)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.createCachedMethodSite(PogoMetaMethodSite.java:206)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.createPogoMetaMethodSite(PogoMetaMethodSite.java:182)
at groovy.lang.MetaClassImpl.createPogoCallCurrentSite(MetaClassImpl.java:3034)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallCurrentSite(CallSiteArray.java:93)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
at Section_1_1348126593121_343308.evaluate(calculator_Section_1_1348126593121_343308:253)
at net.sf.jasperreports.engine.fill.JREvaluator.evaluate(JREvaluator.java:190)
at net.sf.jasperreports.engine.fill.JRCalculator.evaluate(JRCalculator.java:591)
at net.sf.jasperreports.engine.fill.JRCalculator.evaluate(JRCalculator.java:559)
at net.sf.jasperreports.engine.fill.JRFillElement.evaluateExpression(JRFillElement.java:884)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluateText(JRFillTextField.java:421)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluate(JRFillTextField.java:406)
at net.sf.jasperreports.engine.fill.JRFillElementContainer.evaluate(JRFillElementContainer.java:257)
at net.sf.jasperreports.engine.fill.JRFillBand.evaluate(JRFillBand.java:457)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2037)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:771)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportContent(JRVerticalFiller.java:301)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:148)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:909)
As a first bet...
Try to increase the perm gen size, like this:
-XX:MaxPermSize=128m
By default its 64m.
Hope this helps