Tomcat memory overflow Summary

In the production environment, if Tomcat memory is not set properly, memory overflow may easily occur. The memory causes are different, and the processing methods are also different.
Here we will summarize the situation and relevant information. There are three common cases:
1. outofmemoryerror: Java heap Space
2. outofmemoryerror: permgen Space
3. outofmemoryerror: Unable to create new Native thread.
In the first two cases, you can set the Tomcat JVM parameter when the application does not leak memory. (-XMS-xmx-XX: permsize-XX: maxpermsize)
The last possible reason is to adjust the operating system and tomcat JVM parameters at the same time.

First: heap overflow.
This exception is thrown if 98% is used for GC and the available heap size is less than 2% in JVM.
If there is no memory leakage, you can adjust the-XMS-xmx parameter.
-XMS: initial heap size
-Xmx: Maximum heap size
However, the heap size is affected by the following three factors:
1. Restrictions on the data model (32-bit or 64-bit) of the relevant operating system; (32-bit systems are generally limited to Gbps ~ 2G; I tested 2003 m in the 1.6 Server System (physical memory: 4G and 6g, JDK: 1612), 64 for the operating system, there is no limit to the memory .)
2. Virtual Memory limit available for the system;
3. Physical memory limit available for the system.
You can use the Java-xmx *** M version command to test the heap size. If yes, the JDK version is displayed. If no, an error is returned.
-The XMS-xmx configuration is usually the same, for example, set java_opts =-xms1024m-xmx1024m.

Type 2: Permanently saved region Overflow
Permgen space stands for permanent generation space, which is the permanent storage area of the memory. This part is used to store class and meta information. When the class is loaded, it is placed in the permgen space area. Unlike the heap area where the instance is stored, GC (garbage collection) is not stored in the master Program Permgen space is cleaned up during runtime. Therefore, if your app loads many classes, the permgen space error may occur. This error is common when the web server pre-compile the JSP. However, the current Hibernate and spring projects are prone to such problems. Http://www.javaeye.com/topic/80620? This topic is discussed in the post with page = 1. It may be because these frameworks will dynamically class and jvm gc will not clean up pemgen space, resulting in memory overflow.
This is generally solved by increasing-XX: permsize-XX: maxpermsize.
-XX: permsize: Permanent storage area initial size
-XX: the initial maximum value of the permsize permanent storage area.
This is generally used in combination with the first one, such as set java_opts =-xms1024m-xmx1024m-XX: permsize = 128 M-XX: permsize = 256 m
Note that the maximum heap memory tested by the Java-xmx *** M version command is-xmx and-XX: permsize and, for example, the maximum JVM heap size supported by the system is 1.5 GB, -xmx1024m-XX: permsize = 768 m cannot be run.

Third: A New thread cannot be created.
This phenomenon is rare and strange, mainly due to the ratio of JVM to system memory.
This is strange because the JVM has been allocated a large amount of memory (such as 1.5 GB) by the system, and it must occupy at least half of the available memory. Some people find that the more memory you allocate to the JVM when there are many threads, the more likely the above errors will occur.

The cause of this phenomenon is as follows (from this blog to understand the cause: http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html ):

Each 32-bit process can use up to 2 GB of available memory, because the other 2 GB is retained by the operating system. Assume that GB memory is used for JVM, then MB of memory is available. The part of the 400 MB memory must be used for system DLL loading, and the rest may only be mb. Now the key point is: When you use Java to create a thread, A thread object will also be created in the JVM memory, but a real physical thread will also be created in the operating system (refer to JVM specifications ), the operating system will create this physical thread in the remaining 400 mb of memory, instead of creating it in the JVM's MB memory heap. In JDK, the default stack size is kb, but in JDK, the default stack size is 1 MB per Thread. Therefore, up to 400 available threads can be created in the remaining MB of available memory.

This is the conclusion. to create more threads, you must reduce the maximum memory allocated to the JVM. Another way is to host the JVM in your JNICodeInside.

An Estimation Formula for the maximum number of threads that can be created is provided:

(Maxprocessmemory-jvmmemory-reservedosmemory)/(threadstacksize) = number of threads

For JDK, assume that the operating system retains MB of memory:
1.5 gb jvm: (2gb-1.5gb-120mb)/(1 MB) = ~ 380 threads
1.0 gb jvm: (2gb-1.0gb-120mb)/(1 MB) = ~ 880 threads
In boot. ini of 2000/XP/2003, there is a startup option, which seems to be:/PAE/3GAllows the user process to expand the maximum memory to 3 GB. At this time, the operating system can only occupy up to 1 GB of virtual memory. In this way, the JVM should be able to create more threads.
Therefore, adjustments must be made based on the operating system.

Therefore, we need to diagnose Tomcat memory allocation based on different situations to fundamentally solve the problem.

References (benefit from these materials ):
Http://www.javaeye.com/topic/80620? Page = 1
Http://ggmm.blog.sohu.com/117545379.html
Http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html
Http://www.wujianrong.com/archives/2006/12/javalangoutofmemoryerror_permg.html