JVM memory overflow and reasonable configuration in "go" 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) ".

Simply put, the heap is Java code memory, is left to developers to use;

Non-heap is the JVM left to itself, so the method area, JVM internal processing or optimization of the required memory (such as the JIT compiled code cache), each class structure (such as running a constant pool, field and method data), and methods and construction methods of code are in non-heap memory, it is different from the heap, The GC does not release its space during the run time.

1. Heap memory allocation

The initial memory allocated by the JVM is specified by-XMS, which defaults to 1/64 of the physical memory;

The maximum allocated memory for the JVM is specified by-XMX, which defaults to 1/4 of the physical memory.

When the default free heap memory is less than 40%, the JVM will increase the heap until the maximum limit of-xmx;

When free heap memory is greater than 70%, the JVM will reduce 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-XMS-XMX provided by the JVM, and it is recommended that the maximum heap value be set to 80% of the maximum available memory.

program in the case of heavy load will take up more memory, at this time this parameter is very important, if the JVM is set to start when the memory used is relatively small and in this case there are many objects to initialize, The JVM must repeatedly increase memory to satisfy its 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 allocation
Also known as a permanently saved area for storing class and meta information, class 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 the permanent Save area (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;

The JVM uses -xx:maxpermsize to set the maximum amount of non-heap memory, 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 (maximum)

First, the 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. Parameters for JVM memory allocation settings

-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: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:

    
-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 eclipse-Window-Preferences-java-installed JRE (valid for Java programs running in the current development environment) edit the currently used JRE, and in the default VM parameters, enter:-xmx128m-xms64m-  xmn32m–xss16m.    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 and edit the Catalina.bat .%catalina_opts% (total around) replaced by:-xmx128m-xms64m-xmn32m-xss16m. C. If there is no catalina.bat, only tomcat.exe,tomcat6w.exe; you can right-click Configure after starting Tomcat6w.exe--java--under Java option, enter:-xmx256m–xms64m can also find the registry Hkey_local_machine\software\apache software Foundation\tomcatservice Manager\Tomcat6\ Parameters\javaoptions
The original value is-dcatalina.home="C:\ApacheGroup\Tomcat 6.0"-djava.endorsed.dirs="C:\ApacheGroup\Tomcat 6.0\common\endorsed"-xrs
Join-xms300m-xmx350m Restart the Tomcat service and the settings take effect. 

3. View JVM Memory Information

// maximum available memory, corresponding to the-XMX default value of 1/4 of physical memory, set not higher than the physical memory of the computer

// current JVM free memory because the JVM consumes physical memory only when memory is needed, so the value of freememory () is generally small
The actual available memory of the JVM is not equal to freememory () and should be equal to MaxMemory ()-totalmemory () +freememory ().

// The total amount of memory occupied by the current JVM, which is equal to the sum of the Memory and Freememory () used by the current JVM, and increases as the JVM uses memory.

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 memory needs of your application, it will be quick to collect, 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 not exceed
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 above non-heap objects.

The JVM has 2 GC threads:
The first thread is responsible for recovering the young area of the heap;
When the second thread is running out of heap, the heap is traversed, the young area is upgraded to the older area, the size of the older area is equal to-xmx minus the-xmn, and the-XMS value 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.

Attention:
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 "go" tomcat