1)java.lang.OutOfMemoryError: PermGen space
Information related to the perm space:
The permanent generation is the area of heap that holds all the reflective data of the virtual machine itself, such as class and method objects (also called “method area” in The Java Virtual Machine Specification).
If an application loads “too many” classes then it is possible it will abort with an OutOfMemoryError.
The specific error is: “Exception in thread XXXX java.lang.OutOfMemoryError: PermGen space”.
The JVM itself needs memory to be able to run your application.
The PermGen is information about the classes that make up your application. Web applications and Servlet containers often need more PermGen memory than the JVM defaults to be able to run.
Fixing the java.lang.OutOfMemoryError: PermGen space error: Start your JVM with -XX:MaxPermSize=XXXm where XXX is a number like 256. This will allow the JVM to allocate XXX megabytes of memory for the PermGen space if that space is needed.
2)Information related to determining Memory Requirements:
How do I determine how much memory I need?
Weblogic recommends that you install a minimum of 256 MB of memory for each machine running Weblogic Server that will be handling more than minimal capacity.
If you are expecting a very heavy load then you increase your memory substantially.
A Weblogic Server deployment tracks session objects in memory, either to RAM or swapping to disk. There must be sufficient RAM/disk to store all the session objects. This RAM is accessible to Java through the Java heap.
Out of memory in java heap:
JVM throws java out of memory (java OOM) error if it is not able get more memory in java heap to allocate more java objects. The JVM cannot allocate more java objects if the java heap is full of live objects and it is not able to expand the java heap anymore.
In this situation, the JVM lets the application decide on what to do after throwing the java.lang.OutOfMemoryError.
For example, the application may handle this error and decide to shut down itself in a safe way or decide to run ignoring this error. If the application doesn’t handle this error, then the thread that throws this error will exit (you will not see this thread if you take a java thread dump).
In case of Weblogic server, this error is handled if it is thrown by an execute thread and the error is logged. If this error is being thrown continuously, then the core health monitor thread shuts down the Weblogic server.
Steps to follow in case of java OOM
a) Increase the java heap - Try increasing the java heap to see whether that solves the problem.
b) Caching in the application - If the application caches java objects in memory, then we should make sure that this cache is not growing constantly. There should be a limit for the number of objects in the cache. We can try reducing this limit to see if it reduces the java heap usage.
Java soft references can also be used for data caching as softly reachable objects are guaranteed to be removed when the JVM runs out of java heap.
c) Long living objects - If there are long living objects in the application, and then we can try reducing the life of the objects if possible. For example, tuning HTTP session timeout will help in reclaiming the idle session objects faster.
d) Add ‘-verbosegc’ flag in the java command line - This will print GC activity info to stdout/stderr. Redirect the stdout/stderr to a file. Run the application until the problem gets reproduced.
Make sure that the JVM does the following before throwing java OOM
Full GC run: Does a full GC and all the un-reachable, phantomly, weakly and softly reachable objects are removed and those spaces are reclaimed.
We can check whether full GC was done before the OOM message. A message like this is printed when a full GC is done (format varies depending on the JVM – Check JVM help message to understand the format)
[memory ] 7.160: GC 131072K->130052K (131072K) in 1057.359 ms
The format of the above output is (I will stick to the same format throughout this document) :
[memory ]: GC K->K (K), ms
[memory ] - start time of collection (seconds since jvm start)
[memory ] - memory used by objects before collection (KB)
[memory ] - memory used by objects after collection (KB)
[memory ] - size of heap after collection (KB)
[memory ] - total time of collection (milliseconds)
e) Memory leaks – One example of memory leak is when using database connection pools in application server. When using connection pools, the JDBC statement and resultset objects must be explicitly closed in a finally block.
This is due to the fact that calling close() on the connection objects from pool will simply return the connection back to the pool for re-use and it doesn’t actually close the connection and the associated statement/resultset objects.
It is recommended to follow the coding practices suggested in the following URLs to avoid memory leaks in your application.
http://download-llnw.oracle.com/docs/cd//E13222_01/wls/docs103/jdbc/troubleshooting.html
3)Information related to modifying the classpath:
After installation, Weblogic Server’s classpath is already set, but you may choose to modify it for a number of reasons such as adding a patch to Weblogic Server, updating the version of PointBase you are using, or adding support for Log4j logging.
To apply a patch to ALL of your Weblogic Server domains without the need to modify the classpath of a domain, give the patch JAR file the name, weblogic_sp.jar, and copy it into the WL_HOME/server/lib directory. The commEnv.cmd/sh script will automatically include a JAR named weblogic_sp on the classpath for you.
If you would rather not use the name weblogic_sp.jar for your patch file or you would just like to make sure a JAR file, such as one mentioned below, comes before weblogic.jar on the classpath:
* For ALL domains, edit the commEnv.cmd/sh script in WL_HOME/common/bin and prepend your JAR file to the WEBLOGIC_CLASSPATH environment variable.
* To apply a patch to a SPECIFIC Weblogic Server domain, edit the setDomainEnv.cmd/sh script in that domain’s bin directory, and prepend the JAR file to the PRE_CLASSPATH environment variable.
Information related to the perm space:
The permanent generation is the area of heap that holds all the reflective data of the virtual machine itself, such as class and method objects (also called “method area” in The Java Virtual Machine Specification).
If an application loads “too many” classes then it is possible it will abort with an OutOfMemoryError.
The specific error is: “Exception in thread XXXX java.lang.OutOfMemoryError: PermGen space”.
The JVM itself needs memory to be able to run your application.
The PermGen is information about the classes that make up your application. Web applications and Servlet containers often need more PermGen memory than the JVM defaults to be able to run.
Fixing the java.lang.OutOfMemoryError: PermGen space error: Start your JVM with -XX:MaxPermSize=XXXm where XXX is a number like 256. This will allow the JVM to allocate XXX megabytes of memory for the PermGen space if that space is needed.
2)Information related to determining Memory Requirements:
How do I determine how much memory I need?
Weblogic recommends that you install a minimum of 256 MB of memory for each machine running Weblogic Server that will be handling more than minimal capacity.
If you are expecting a very heavy load then you increase your memory substantially.
A Weblogic Server deployment tracks session objects in memory, either to RAM or swapping to disk. There must be sufficient RAM/disk to store all the session objects. This RAM is accessible to Java through the Java heap.
Out of memory in java heap:
JVM throws java out of memory (java OOM) error if it is not able get more memory in java heap to allocate more java objects. The JVM cannot allocate more java objects if the java heap is full of live objects and it is not able to expand the java heap anymore.
In this situation, the JVM lets the application decide on what to do after throwing the java.lang.OutOfMemoryError.
For example, the application may handle this error and decide to shut down itself in a safe way or decide to run ignoring this error. If the application doesn’t handle this error, then the thread that throws this error will exit (you will not see this thread if you take a java thread dump).
In case of Weblogic server, this error is handled if it is thrown by an execute thread and the error is logged. If this error is being thrown continuously, then the core health monitor thread shuts down the Weblogic server.
Steps to follow in case of java OOM
a) Increase the java heap - Try increasing the java heap to see whether that solves the problem.
b) Caching in the application - If the application caches java objects in memory, then we should make sure that this cache is not growing constantly. There should be a limit for the number of objects in the cache. We can try reducing this limit to see if it reduces the java heap usage.
Java soft references can also be used for data caching as softly reachable objects are guaranteed to be removed when the JVM runs out of java heap.
c) Long living objects - If there are long living objects in the application, and then we can try reducing the life of the objects if possible. For example, tuning HTTP session timeout will help in reclaiming the idle session objects faster.
d) Add ‘-verbosegc’ flag in the java command line - This will print GC activity info to stdout/stderr. Redirect the stdout/stderr to a file. Run the application until the problem gets reproduced.
Make sure that the JVM does the following before throwing java OOM
Full GC run: Does a full GC and all the un-reachable, phantomly, weakly and softly reachable objects are removed and those spaces are reclaimed.
We can check whether full GC was done before the OOM message. A message like this is printed when a full GC is done (format varies depending on the JVM – Check JVM help message to understand the format)
[memory ] 7.160: GC 131072K->130052K (131072K) in 1057.359 ms
The format of the above output is (I will stick to the same format throughout this document) :
[memory ]
[memory ]
[memory ]
[memory ]
[memory ]
[memory ]
e) Memory leaks – One example of memory leak is when using database connection pools in application server. When using connection pools, the JDBC statement and resultset objects must be explicitly closed in a finally block.
This is due to the fact that calling close() on the connection objects from pool will simply return the connection back to the pool for re-use and it doesn’t actually close the connection and the associated statement/resultset objects.
It is recommended to follow the coding practices suggested in the following URLs to avoid memory leaks in your application.
http://download-llnw.oracle.com/docs/cd//E13222_01/wls/docs103/jdbc/troubleshooting.html
3)Information related to modifying the classpath:
After installation, Weblogic Server’s classpath is already set, but you may choose to modify it for a number of reasons such as adding a patch to Weblogic Server, updating the version of PointBase you are using, or adding support for Log4j logging.
To apply a patch to ALL of your Weblogic Server domains without the need to modify the classpath of a domain, give the patch JAR file the name, weblogic_sp.jar, and copy it into the WL_HOME/server/lib directory. The commEnv.cmd/sh script will automatically include a JAR named weblogic_sp on the classpath for you.
If you would rather not use the name weblogic_sp.jar for your patch file or you would just like to make sure a JAR file, such as one mentioned below, comes before weblogic.jar on the classpath:
* For ALL domains, edit the commEnv.cmd/sh script in WL_HOME/common/bin and prepend your JAR file to the WEBLOGIC_CLASSPATH environment variable.
* To apply a patch to a SPECIFIC Weblogic Server domain, edit the setDomainEnv.cmd/sh script in that domain’s bin directory, and prepend the JAR file to the PRE_CLASSPATH environment variable.
No comments:
Post a Comment