Linux/centos Troubleshooting Tomcat Memory Overflow

Tomcat itself cannot be run directly on the computer, it needs to rely on the operating system and a Java virtual machine. When the Java program starts, the JVM allocates an initial memory and a maximum memory to the app. When the app needs more memory than the maximum memory value, the virtual machine prompts for a memory overflow and causes the app service to crash.

One, the common Java memory overflow has the following three kinds:

1. Java.lang.OutOfMemoryError:Java heap space is the JVM heap overflow

Explanation: The JVM will automatically set the value of the JVM heap when it is started, and the JVM heap setting is the set of memory space that the JVM can provision for use during the Java program's run. The initial space is 1/64 of the physical memory by default, and the maximum space cannot exceed the physical memory. The JVM provides options such as-xmn-xms-xmx to set.

Error scenario: JVM heap overflow occurs in JVM if 98% of the time is used for GC and the available heap size is less than 2%

Workaround: Modify the size of the JVM heap.

2. Java.lang.OutOfMemoryError:PermGen space is PermGen space overflow

Explanation: PermGen space refers to the permanent storage area of memory. This area mainly stores class and meta information, and class is placed in PermGen space when it is loaded.

Error scenario: If the app loads many classes, a permgen space overflow may occur. (because Sun's GC does not clean up PermGen space while the program is running)

Common when a Web server pre-compile a JSP

Workaround: Modify the MaxPermSize size

3. Java.lang.StackOverflowError is the stack Overflow

Explanation: The JVM is using a stack of virtual machines, and the process of invoking functions is on the stack and on the fallback stack.

Error scenario: The size of the stack is usually 1-2mb, and if the "layer" of the constructor is called too many, a stack overflow will occur

Workaround: Modify the program

Second, Tomcat's JVM memory overflow solution

In a production environment, Tomcat memory settings are not good enough to be prone to JVM memory overflow, and the workaround is to modify the catalina.sh file in Tomcat.

In the catalina.sh file, locate Cygwin=false, and add the parameters in front of this line, as follows

# vi tomcat_home/bin/catalina.shjava_opts= "-SERVER-XMS800M-XMX800M-XX:PERMSIZE=256M-XX:MAXPERMSIZE=512M-XX: Maxnewsize=512m "

Other Notes:

1. "M" indicates the unit is MB, otherwise the default is KB

2. Generally use 80% of physical memory as the heap size

3.-xms and-XMX are generally set to the same size

4. Generally set the-xmn to 1/4 of the-XMX value

5. Generally allocate 50% to 60% of the total size of the heap to the newly generated pool

Third, JVM parameter description:

-server Be sure to enable the server version of the JDK as the first parameter, with good performance over multiple CPUs

-xms java heap Initial size. The default is 1/64 of physical memory.

-xmx Java heap maximum value. The recommendation is set to 80% of physical memory. Do not exceed physical memory.

-xmn Java heap minimum, typically set to one of the 3, 4 points of xmx.

-xx:permsize sets the initial size of the memory's permanent save area, and the default value is 64M.

-xx:maxpermsize set the maximum size of the memory's permanent storage, the default value is 64M.

The size of the-xx:survivorratio=2 survivor pool is 2 by default. If garbage collection becomes a bottleneck, you can try customizing the build pool settings

-xx:newsize the initial size of the newly generated pool. The default value is 2M.

-xx:maxnewsize the maximum size of the newly generated pool. The default value is 32M.

+xx:aggressiveheap lets the JVM ignore the xmx parameter, frantically eats a g of physical memory and eats a G swap.

-XSS stack size per thread

-VERBOSE:GC Reality Garbage Collection Information

-xloggc:gc.log specifying garbage collection log files

-XX:+USEPARNEWGC shortening the time of minor collection

-XX:+USECONCMARKSWEEPGC shortening the time of major collection

-XX:USERPARNEWGC can be used to set up parallel collection (multi-CPU)

-xx:parallelgcthreads can be used to increase the degree of parallelism (multi-CPU)

-XX:USEPARALLELGC can be set with a parallel purge collector (multi-CPU)

This article from "Doiido" blog, reproduced please contact the author!

Linux/centos Troubleshooting Tomcat Memory Overflow