JVM memory overflow and reasonable configuration in Tomcat

Tomcat itself cannot run directly on the computer, it needs to rely on a hardware-based operating system and a Java virtual machine. Tomcat's memory overflow is essentially a JVM memory overflow, so at the beginning of this article, the Java JVM's memory-related knowledge should be described in detail.

First, Java JVM memory Introduction

The JVM manages two types of memory, heap, and non-heap. According to the official statement, "Java virtual machines have a heap, the heap is a runtime data region, and all class instances and arrays of memory are allocated from here." The heap is created when the Java virtual machine is started. "" The memory outside the heap in the JVM is called non-heap (non-heap memory) ". In a nutshell, a heap is a Java code-readable memory that is left to the developer, not a heap, which is left to itself by the JVM, so the method area, the JVM internally processes or optimizes the required memory (such as the JIT-compiled code cache), each class structure (such as running a constant pool, field, and method data) And the code for methods and construction methods are in non-heap memory, and unlike heaps, the GC does not free its space during the run time.

(1). Heap memory allocation JVM initially allocates memory specified by-XMS, the default is physical memory 1/64;JVM the maximum allocated memory is specified by-XMX, which defaults to 1/4 of physical memory. When the default free heap memory is less than 40%, the JVM increases the heap until the maximum limit of-xmx, and when the free heap memory is greater than 70%, the JVM reduces the heap until the minimum limit of-XMS. So the server generally sets-xms,-xmx equal to avoid resizing the heap after each GC. You can make heap memory settings with options such as the-XMN-XMS-XMX provided by the JVM, generally to set the-XMS and-XMX options to the same, and the-XMX value of-xmn to 1/4, the recommended maximum value for the heap is set to 80% of the maximum available memory.

The size of the initialization heap is the amount of memory that the JVM requests to the system at startup. Generally speaking, this parameter is not important. However, some applications in the case of heavy load will take up more memory, when this parameter is very important, if the JVM is set to start when the memory is relatively small and in this case there are many objects to initialize, the JVM must repeatedly increase the memory to meet the use. For this reason, we generally set-XMS and-xmx as large, and the maximum value of the heap is limited by the physical memory used by the system. Applications that use large amounts of data generally use persistent objects, and memory usage can grow rapidly. The JVM prompts for memory overflow when the application needs more memory than the heap, and causes the app service to crash. Therefore, if XMS exceeds the XMX value, or if the sum of the heap maximum and the non-heap maximum exceeds the physical memory or the maximum limit of the operating system, the server will not start up.

(2). Non-heap memory allocations are also called permanently saved areas for class and meta information, which is placed in the zone when it is loaded. Unlike the heap area where the class instance (Instance) is stored, the GC (garbage Collection) does not clean up permgen space during the main program run time. The JVM uses-xx:permsize to set the non-heap memory initial value, which defaults to 1/64 of the physical memory, and the maximum non-heap memory by Xx:maxpermsize, which by default is 1/4 of physical memory. GC does not clean up permgen space, so if your app will load a lot of classes, you will likely have permgen space errors.

(3). JVM Memory Limit (max) first JVM memory is limited to the actual maximum physical memory (nonsense!). , hehe), assuming that the physical memory is infinitely large, the maximum value of the JVM memory is very much related to the operating system. Simply put, 32-bit processor Although the controllable memory space has 4GB, but the specific operating system will give a limit, this limit is generally 2GB-3GB (generally speaking, Windows system under the 1.5g-2g,linux system for 2G-3G), There is no limit to processors over 64bit.

Description of two or three memory overflow exceptions

1. Heap overflow in Outofmemoryerror:java heap space

The main problem with memory overflow is that it appears in this case. This exception message is thrown when 98% of the time in the JVM is used for GC and the available HEAP size is less than 2%.

2. Outofmemoryerror:permgen Space Non-heap overflow (permanent save area overflow)

This error is common when the Web server pre-compile the JSP. If you have a large number of third-party jars under your web app that are larger than the JVM's default size (4M), this error message will be generated. If the Web app uses a large number of third-party jars, or if the application has too many class files, and the MaxPermSize setting is small, exceeding this will cause the memory to overflow too much, or the Tomcat hot deployment will not clean up the previously loaded environment, Only the context is changed to the newly deployed, and the non-stockpiled content becomes more and more.

3. Outofmemoryerror:unable to create new native thread. Unable to create 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.

Third, Java JVM memory configuration

1. The JVM memory allocation setting has four parameters

-xmx Java Heap Maximum, the default value is 1/4 of physical memory;

-xms Java Heap Initial value, the server side JVM is best to set-XMS and-xmx to the same value, the development tester JVM can retain the default value;

-xmn Java Heap Young area size, not familiar with the best to keep the default value;

-XSS the stack size of each thread, not familiar with the best to keep the default value;

-xx:permsize: Set the permanent storage area of memory;

-xx:maxpermsize: Set the maximum memory of the permanent storage area;

-xx:permsize: Set the permanent storage area of memory;

-xx:newsize: Sets the default size of the ' Cenozoic ' of the JVM heap;

-xx:maxnewsize: Sets the maximum size of the ' Cenozoic ' of the JVM heap;

2. How to set the JVM's memory allocation

(1) When starting and using the JVM at the command prompt (only for the currently running class test):

java-xmx128m-xms64m-xmn32m-xss16m Test

(2) When you start and use the JVM in an integrated development environment, such as Eclipse:

A. Open Eclipse.ini in the Eclipse root, the default content is (here is the JVM memory allocation running the current development tool):-vmargs-xms40m-xmx256m-vmargs indicates that the following is a set of parameters for the virtual machine, you can modify the parameter values, You can also add-xmn,-xss, in addition, Eclipse.ini can also set non-heap memory, such as:-xx:permsize=56m,-xx:maxpermsize=128m.

B. Open the Eclipse-window-preferences-java-the installed JRE (valid for Java programs running in the current development environment), edit the currently used JRE, and enter:-xmx128m-xms64m-xmn32m–xss16m in the default VM parameter.

C. Open eclipse-Run-run-java application (only valid for the Java class you set) Select the class-independent variable that you want to set the memory allocation for, and enter it in the VM argument:-xmx128m-xms64m-xmn32m-xss16m Note: If both the B and C settings are in the same development environment, the B setting takes effect and the C setting is not valid, such as:-xmx256m is set for the development environment, and class test is set to:-xmx128m-xms64m, the setting that is in effect when the test is run is:-xmx256m- xms64m.

(3) When the JVM is started and used in a server environment (such as Tomcat) (the Java program is in effect for the current server environment):

A. Setting environment variables: variable name: catalina_opts variable Value:-xmx128m-xms64m-xmn32m-xss16m.

B. Open the Bin folder under the Tomcat root directory, edit Catalina.bat, and replace the%catalina_opts% (all around) with the following:-xmx128m-xms64m-xmn32m-xss16m.

C. If there is no catalina.bat, only tomcat.exe,tomcat6w.exe; you can right-click Configure--java--java option under Start Tomcat6w.exe to enter:

-xmx256m–xms64m

You can also find the registry Hkey_local_machine\software\apache software Foundation\tomcatservice manager\tomcat6\parameters\ Javaoptions Original value is-dcatalina.home= "C:\ApacheGroup\Tomcat 6.0"-djava.endorsed.dirs= "C:\ApacheGroup\Tomcat 6.0\common\ Endorsed "-xrs joins the-xms300m-xmx350m (I'm adding-xmx350m,tomcat to start, adding-xms300m-xmx350m instead of tomcat can boot) Restart the Tomcat service and the settings take effect.

3. View JVM Memory Information

Runtime.getruntime (). MaxMemory (); Maximum available memory, corresponding to-XMX

Runtime.getruntime (). Freememory (); Current JVM free memory

Runtime.getruntime (). TotalMemory (); The total amount of memory occupied by the current JVM, which is equivalent to the sum of the memory used by the current JVM and the Freememory ()

About MaxMemory (), Freememory (), and TotalMemory (): MaxMemory () is the maximum available memory for the JVM, which can be set by-XMX, and the default value is 1/4 of physical memory and cannot be set higher than the physical memory of the computer; TotalMemory () is the total amount of memory occupied by the current JVM, which is equal to the sum of the memory used by the current JVM and the Freememory (), which increases as the JVM uses memory, and Freememory () is the current JVM's free memory. Because the JVM consumes physical memory only when it needs memory, the value of freememory () is generally small, and the actual available memory of the JVM is not equal to freememory () and should be equal to MaxMemory ()-totalmemory () + Freememory ().

4. Example, the following gives a reference to the parameter setting of the Java JVM in the 1G memory environment

Java_opts= "-server-xms800m-xmx800m-xx:permsize=64m-xx:maxnewsize=256m-xx:maxpermsize=128m-djava.awt.headless= True "

Large Web projects with tomcat default allocated memory space cannot be started, and if not started in MyEclipse Tomcat can be set for Tomcat:

Add such a sentence in Tomcat_home\bin\catalina.bat:

Set java_opts=-xmx1024m-xms512m-xx:maxpermsize=256m

If you want to start in MyEclipse, the above modifications will not work, and can be set as follows:

In the MYECLIPSE->PREFERENCES->MYECLIPSE->SERVERS->TOMCAT->TOMCATX.X->JDK panel

Optional Java VM arguments added:-xmx1024m-xms512m-xx:maxpermsize=256m

For a separate. Class, you can set the JVM memory of the test runtime using the following method. java-xms64m-xmx256m TEST-XMS is the size of the set memory initialization-xmx is the maximum amount of memory that can be used.

Iv. JVM Memory configuration vs. GC

What you need to consider is the garbage collection mechanism provided by Java. The JVM's heap size determines the amount of time and frequency that the JVM spends collecting garbage. The rate at which garbage collection can be accepted is related to the application and should be adjusted by analyzing the time and frequency of actual garbage collection. If the heap size is large, then the total garbage collection will be slow, but the frequency will be reduced. If you match the size of the heap to the needs of the memory, it will be collected very quickly, but more often. The purpose of sizing the heap is to minimize garbage collection time to maximize processing of customer requests over a specific time period. In benchmarking, to ensure the best performance, the size of the heap to be large, to ensure that garbage collection does not occur throughout the baseline test process. If your system spends a lot of time collecting garbage, reduce the heap size. A complete garbage collection should be no more than 3-5 seconds. If garbage collection becomes a bottleneck, you need to specify the size of the heap, examine the detailed output of the garbage collection, and investigate the performance impact of garbage collection parameters. Generally speaking, you should use 80% of the physical memory as the heap size. When adding processors, remember to increase the memory because allocations can be done in parallel, and garbage collection is not parallel.

The Java heap is divided into 3 zones:

1.Young 2.Old 3.Permanent. Young saves the object that was just instantiated. When the area is filled, the GC moves the object to the old area. The permanent area is responsible for saving the reflected object, which is not discussed in this article.

The JVM has 2 GC threads: The first thread is responsible for recovering the young area of the heap, the second thread is traversing the heap when the heap is low, and the young area is upgraded to the older area, and the size of the older area equals-xmx minus-xmn. The value of the-XMS cannot be set too large because the second thread is forced to run to degrade the performance of the JVM.

Why do some programs frequently occur in GC? There are the following reasons: 1. System.GC () or RUNTIME.GC () is called within the program. 2. Some middleware software calls its own GC method, at which time you need to set parameters to prohibit these GC. 3. Java's heap is too small, and the default heap values are generally small. 4. Frequent instantiation of objects, release objects try to save and reuse objects at this time, such as using StringBuffer () and string ().

If you find that after each GC, the remaining space in the heap will be 50% of the total space, which means that your heap is in a healthy state. Many server-side Java programs have a better 65% space left after each GC.

Experience : 1. The server-side JVM is best to set-XMS and-xmx to the same value. In order to optimize GC, it is best to make-xmn value approximately equal to 1/3 of-XMX. 2. A GUI program is best to run a GC every 10-20 seconds, each time within half a second.

Note: 1. Increasing the size of the heap decreases the frequency of the GC, but it also increases the time of each GC. And when the GC runs, all the user threads are paused, that is, during the GC, the Java application does not do any work. 2. The heap size does not determine the amount of memory used by the process. The memory usage of the process is greater than the value defined by-XMX because Java allocates memory for other tasks, such as the stack for each thread.

JVM memory overflow and reasonable configuration in Tomcat