Hello Everyone,
Today one of WAS 8.0.0.5 Server get crashed and was showing the below error in SystemOut.log
[04/03/15 10:27:47:004 GMT] 00013e2b servlet E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0014E: Uncaught service() exception root caus
e spring-ws: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.OutOfMemoryError: PermGen space
As it's a java application running of WebSphere Application server it allocate some memory to run. The size of memory is split into different areas including PermGen Space. The size of all these areas set during the JVM startup. If you do not set the sizes yourself, platform specific defaults will be used. So the “java.lang.OutOfMemoryError: PermGen space” message indicates that the Permanent Size area in memory is exhausted. And there are lot of reasons for this.
All Java classes are loaded and stored in the Java PermGen.All of these are allocated to PermGen and stay in PermGen.As you can see, the PermGen size requirements depend both upon the number of classes loaded as well as the size of such class declarations. So it is easy to see the main cause for the “java.lang.OutOfMemoryError: PermGen space“: either too many classes or too big classes are being loaded to the permanent generation.
The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough below room. So alter your application launch configuration and add (or increase if present) the following:
-XX:MaxPermSize=512m (Suitable Size)
This configuration parameter is indicating to the JVM that PermGen is allowed to grow up to 512 MB before complaining in the form of OutOfMemoryError.
Second Solution is you can take the heap dump at the time of issue and analyze it to find which objects causes the OutOfMemoryError in PermGen space
Third possibility is to allow GC to unload classes from PermGen. The standard JVM is rather conservative in this regard Classes are born to live forever. So once loaded, classes stay in memory even if no one is really using them anymore. This can become a problem when the application is creating lots of classes dynamically and the generated classes are not needed for longer periods. In such a case, allowing JVM to unload class definitions can be helpful. This is achieved by adding again just one configuration parameter to your startup scripts:
-XX:+CMSClassUnloadingEnabled
By default this is set to false and so to enable this you need to explicitly set the following option in Java options. If you enable CMSClassUnloadingEnabled, GC will sweep PermGen too and remove classes which are no longer used. Keep in mind that this option will work only when UseConcMarkSweepGC is also enabled using the below option. So when running parallel or, God forbid, serial GCs, make sure you have set your GC to CMS by specifying:
-XX:+UseConcMarkSweepGC
But before calling it a night, be warned more often than not usage of the recommended “quick fixes” means you are just masking the symptoms by hiding “java.lang.OutOfMemoryError: Permgen space” and are not tackling the underlying problem.
I personally recommend you to use the 1st and 2nd solution. And hope it will help you to resolve the issue.
"Effort only fully releases its reward after a person refuses to quit.”
Regards,
Akhilesh B. Humbe
Today one of WAS 8.0.0.5 Server get crashed and was showing the below error in SystemOut.log
Error:
[04/03/15 10:27:47:004 GMT] 00013e2b servlet E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0014E: Uncaught service() exception root caus
e spring-ws: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.OutOfMemoryError: PermGen space
Cause:
As it's a java application running of WebSphere Application server it allocate some memory to run. The size of memory is split into different areas including PermGen Space. The size of all these areas set during the JVM startup. If you do not set the sizes yourself, platform specific defaults will be used. So the “java.lang.OutOfMemoryError: PermGen space” message indicates that the Permanent Size area in memory is exhausted. And there are lot of reasons for this.
All Java classes are loaded and stored in the Java PermGen.All of these are allocated to PermGen and stay in PermGen.As you can see, the PermGen size requirements depend both upon the number of classes loaded as well as the size of such class declarations. So it is easy to see the main cause for the “java.lang.OutOfMemoryError: PermGen space“: either too many classes or too big classes are being loaded to the permanent generation.
Solution:
The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough below room. So alter your application launch configuration and add (or increase if present) the following:
-XX:MaxPermSize=512m (Suitable Size)
This configuration parameter is indicating to the JVM that PermGen is allowed to grow up to 512 MB before complaining in the form of OutOfMemoryError.
Second Solution is you can take the heap dump at the time of issue and analyze it to find which objects causes the OutOfMemoryError in PermGen space
Third possibility is to allow GC to unload classes from PermGen. The standard JVM is rather conservative in this regard Classes are born to live forever. So once loaded, classes stay in memory even if no one is really using them anymore. This can become a problem when the application is creating lots of classes dynamically and the generated classes are not needed for longer periods. In such a case, allowing JVM to unload class definitions can be helpful. This is achieved by adding again just one configuration parameter to your startup scripts:
-XX:+CMSClassUnloadingEnabled
By default this is set to false and so to enable this you need to explicitly set the following option in Java options. If you enable CMSClassUnloadingEnabled, GC will sweep PermGen too and remove classes which are no longer used. Keep in mind that this option will work only when UseConcMarkSweepGC is also enabled using the below option. So when running parallel or, God forbid, serial GCs, make sure you have set your GC to CMS by specifying:
-XX:+UseConcMarkSweepGC
But before calling it a night, be warned more often than not usage of the recommended “quick fixes” means you are just masking the symptoms by hiding “java.lang.OutOfMemoryError: Permgen space” and are not tackling the underlying problem.
I personally recommend you to use the 1st and 2nd solution. And hope it will help you to resolve the issue.
"Effort only fully releases its reward after a person refuses to quit.”
Regards,
Akhilesh B. Humbe
No comments:
Post a Comment