Analysis and resolution of the cause of Tomcat memory overflow

There are a lot of introductions on the internet, but they are not comprehensive, this article synthesizes several articles common group from.

In a production environment, tomcat memory settings are not good enough to be prone to memory overflow . The reason for the memory is not the same, of course, the processing method is not the same.

Here according to the usual situation and relevant information to carry out a summary. Commonly, there are three situations:

1.outofmemoryerror:java Heap Space

2.outofmemoryerror:permgen Space

3.outofmemoryerror:unable to create new native thread.

For the first two cases, the tomcat JVM parameters can be resolved with the application itself without a memory leak. (-xms-xmx-xx:permsize-xx:maxpermsize)

The last one may need to adjust the operating system and Tomcat JVM parameters at the same time to achieve the goal.

The first: a heap overflow .

This exception information is thrown in the JVM if 98% of the time is used for GC and the available HEAP size is less than 2%.

In the absence of a memory leak, the tuning-xms-xmx parameter can be resolved.

-XMS: initial Heap Size

-XMX: Maximum Heap Size

However, the size of the heap is affected by the following three aspects:

1. The data model of the relevant operating system (32-BT or 64-bit) is limited, (under 32-bit systems, it is generally limited to 1.5g~2g; I test 6g,jdk:1.6 under the 2003 Server System (physical memory: 4G and 1612m,64) for unlimited memory for the operating system. ）

2. Available virtual memory limits for the system;

3. Available physical memory limits for the system.

The heap size can be tested using the JAVA-XMX***M version command. Support will appear the JDK version number, does not support error.

-XMS-XMX is generally configured to be as good as set java_opts=-xms1024m-xmx1024m

The second type: Permanent save area overflow

The full name of PermGen space is permanent generationspace, which refers to the permanent storage area of memory. This section is used to store class and meta information, and class is placed in the Permgenspace area when it is loaded, unlike the heap area where instance is stored, GC (garbage Collection) Permgenspace will not be cleaned during the main program run time, so if your app will load many classes, you will likely have permgenspace errors. This error is common when the Web server precompile the JSP. But this is also a problem in the current Hibernate and spring projects. Http://www.javaeye.com/topic/80620?page=1 's post has been discussed in this issue. It is possible that these frameworks will be dynamic class, and the JVM's GC will not clean up pemgen space, causing a memory overflow.

This one is generally to increase the-xx:permsize-xx:maxpermsize to solve the problem.

-xx:permsize Permanent Save Area Initial size

-xx:permsize the initial maximum value of the permanently saved area

This is typically used in conjunction with the first one, such as set java_opts=-xms1024m-xmx1024m-xx:permsize=128m-xx:permsize=256m

One thing to note: The java-xmx***m version command to test the maximum heap memory is-xmx with-xx:permsize and for example the system supports the largest JVM heap size thing 1.5G, that-xmx1024m-xx:permsize=768m is not able to run.

Third: You cannot create a new thread.

This phenomenon is relatively rare and strange, mainly related to the ratio of JVM to system memory.

This strange thing is because the JVM has been allocated a large amount of memory (such as 1.5G), and it consumes at least half of the available memory. It has been found that the more memory you allocate to the JVM, the greater the likelihood that the above error will occur, given the large number of threads.

This behavior occurs for the following reasons: Each 32-bit process can use up to 2G of available memory, because another 2G is reserved by the operating system. This assumes that 1.5G is used for the JVM, and then the remaining 500M of available memory. This 500M part of the memory must be used to load the system DLL, then the real left is perhaps only 400M, and now the key point arises: When you use Java to create a thread, in the JVM's memory will also create a thread object, But it also creates a real physical thread in the operating system (referencing the JVM specification), and the operating system creates the physical thread in the remaining 400 megabytes of memory, rather than in the 1500M memory heap of the JVM. In jdk1.4, the default stack size is 256KB, but in jdk1.5, the default stack size is 1M per thread, so we can create up to 400 available threads in the remaining 400M of available memory.

The conclusion is that to create more threads, you must reduce the maximum memory allocated to the JVM. Another option is to have the JVM host inside your JNI code.

Give an estimate formula for the maximum number of threads that can be created:

(maxprocessmemory-jvmmemory-reservedosmemory)/(Threadstacksize) = number of threads

For jdk1.5, assume that the operating system retains 120M of memory:

1.5GB JVM: (2GB-1.5GB-120MB)/(1MB) = ~380 threads

1.0GB JVM: (2GB-1.0GB-120MB)/(1MB) = ~880 threads

In 2000/xp/2003 's boot. INI, there is a boot option, as if:/pae/3g, which allows the user process to expand the maximum memory to 3G, when the operating system can only occupy up to 1G of virtual storage. That should allow the JVM to create more threads.

So this situation needs to be adjusted in conjunction with the operating system.

Therefore: we need to diagnose the Tomcat memory allocation differently in combination with different scenarios to fundamentally solve the problem.

After the reason, how to set it?

There are two kinds of situations:

get "" Springmvc+mybatis Framework Integrated source project download

1, when starting with the console can be in, catalina.bat Front Join   set JAVA_OPTS=- xms128m-xmx350m   ....

2, when started with the service, the method is not the same, which many people neglect. See figure below, only in this setting to take effect, this bothered me for a while.

650) this.width=650; "style=" border-top:0px;border-right:0px;border-bottom:0px;border-left:0px; "src="/HTTP/ Img.my.csdn.net/uploads/201302/20/1361364767_8118.jpg "/>

Of course, you can also configure the registry in the following registry location:

Hkey_local_machine\software\apache Software Foundation\procrun 2.0\tomcat7\parameters

After the above content is configured, these problems should not occur, of course, the program must not have a memory leak.

Analysis and resolution of the cause of Tomcat memory overflow