Server Java.lang.OutOfMemoryError:allocLargeArray Memory Overflow resolution

Today, a Web server is not working, view the log. Tomcat reported the following information:

caused By:java.lang.outofmemoryerror:alloclargearray-object size:80040, Num elements:40010

The above log information basically means that the program assigns a 80040-byte array (the array is also an object in the JVM, and is allocated in heap), and 40010 is the number of exponential group elements. But when allocating this array, there is no space available for heap.

In view of the above, the solution is as follows:

A: Adjust the Java JVM parameters, optimize the Java Virtual machine, and adjust the heap settings appropriately

B: Clean up the system useless log, excellent Apache run parameters. Open the GC log to gather more heap usage information.

For more information about Java JVM Optimizations, see the following:

The principle of the JVM memory setup

The default Java virtual machine size is relatively small, in the processing of large data Java will be an error: Java.lang.OutOfMemoryError.

To set the JVM memory method, for individual. Class, you can set the JVM memory for test runtime in the following ways.

java-xms64m-xmx256m Test

-XMS is to set the size of memory initialization

-XMX is to set the maximum available memory size (preferably not more than the physical memory size)

In WebLogic, you can set the size of each domain virtual memory in Startweblogic.cmd, and the default setting is in Commenv.cmd.

Tuning of JVM Memory

1. Heap Settings and garbage collection Java heap are divided into 3 districts, Young,old and permanent. Young saves a newly instantiated object. When the area is filled, the GC moves the object to the old area. The permanent area is responsible for saving reflection objects, and this article does not discuss the area. The heap allocation of the JVM can be set using the-x parameter.

-XMS: initial Heap Size

-xmx:java Heap Max Value

Heap size of-xmn:young generation

The JVM has 2 GC threads. The first thread is responsible for reclaiming the young area of heap. The second thread, when HEAP is insufficient, traverses the HEAP and upgrades young to the older area. The size of the older area equals-xmx minus-xmn, and the-XMS value cannot be set too large because the second thread is forced to run, which degrades the performance of the JVM.

Why do some programs frequently occur with GC? There are the following reasons:

L the System.GC () or RUNTIME.GC () is called within the program.

L Some middleware software calls its own GC method, at which point you need to set parameters to prohibit these GC.

L Java's heap is too small, the general default heap values are very small.

L frequently instantiate objects, release objects. At this point, try to save and reuse the objects, such as using StringBuffer () and string ().

If you find that after each GC, the remaining space of 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 65% of the remaining space after each GC. Experience:

1. The server-side JVM is best to set-XMS and-xmx to the same value. In order to optimize the GC, it is best to make the-XMN value approximately equal to the-xmx 1/3[2].

2. A GUI program is best to run the GC once every 10-20 seconds, and within half a second to complete [2].