JVM Tuning method _JVM and performance tuning

JVM Tuning Tool

Jconsole,jprofile,visualvm

JCONSOLE:JDK, the function is simple, but can be used in a certain load of the system. The garbage collection algorithm is tracked in detail. Detailed description Reference here

Jprofiler: Commercial software, you need to pay. function is powerful. Detailed description Reference here

VISUALVM:JDK, powerful, similar to Jprofiler. Recommended.

How to Tune

Observe memory release, collection class checking, Object tree

The above tuning tools provide powerful functionality, but generally they are grouped into the following categories of functionality

Heap Information View

Can view heap space allocation (young generation, older generation, persistent generation distribution)

Provides instant garbage collection capabilities

Garbage monitoring (long time monitoring recovery)

View the class in the heap, object information view: quantity, type, etc.

Object reference View

With a heap of information to view the function, we generally can successfully solve the following problems:

--is the size of the younger generation of the elderly reasonable

--Memory leaks

--The garbage collection algorithm setting is reasonable

Thread Monitoring

Thread Information monitoring: number of system threads.

Thread state monitoring: What is the state of each thread

Dump thread Details: View internal running of threads

Deadlock Check

Hot Spot Analysis

CPU hotspots: Check which methods are used by the system for a large amount of CPU time

Memory hotspots: Check which objects are the largest number in the system (live objects and destroy objects are counted together for a certain period of time)

These two things are very helpful for system optimization. We can according to find hotspots, targeted system bottlenecks to find and optimize the system, rather than aimlessly for all the code optimization.

Snapshot

A snapshot is a frame that the system runs to a certain point in time. When we are tuning, it is impossible to use the eye to track all system changes, relying on the snapshot function, we can carry out the system two different Run-time, objects (or classes, threads, etc.) different, so as to quickly find the problem

For example, I want to check if the system has been garbage collected, if there are any objects that have been withdrawn. So, I can take a snapshot of the heap situation before and after the garbage collection, and then compare the objects of the two snapshots.

Memory leak Check

Memory leak is a more common problem, and the solution is also more general, here can focus on, and thread, hot aspects of the problem is specific to the specific analysis.

Memory leaks can generally be understood as system resources (all aspects of resources, heaps, stacks, threads, etc.) in the case of incorrect use, resulting in the use of resources can not be recycled (or not reclaimed), resulting in new resource allocation requests can not complete, causing system errors.

Memory leaks are more harmful to the system because they can cause the system to crash directly.

There is a difference between a memory leak and a system overload, although the end result may be the same. A memory leak is an error caused by unused resources, and system overload is the system does not have so many resources to allocate (other resources are in use).

The old generation heap space is filled up

Exception: Java.lang.OutOfMemoryError:Java heap Space

Description

This is the most typical memory leak way, simply put, all heap space is not recyclable garbage objects, virtual machines can no longer allocate new space.

As shown in the figure above, this is a very typical garbage collection scenario for memory leaks. All peak portions are a garbage collection point, and all bottom sections represent the memory remaining after a garbage collection. Connect all the bottom points, you can find a line from the bottom to the high, which shows that, over time, the system's heap space is constantly occupied, eventually fill the entire heap of space. Therefore, it is possible to initially think that there may be a memory leak inside the system. (The above figure is for example, and it takes longer to collect data in real time, such as hours or days)

Solve:

This approach is also easier to solve, generally based on the situation before and after the garbage collection, at the same time, according to the object reference (Common collection object reference) analysis, the basic can find the leak point.

Persistent generation is fully occupied

Exception: Java.lang.OutOfMemoryError:PermGen space

Description

The perm space is filled up. The exception that is thrown when the storage space cannot be allocated for the new class. This exception was not previously available, but this anomaly is common today when Java reflection is used heavily. The main reason is that a large number of dynamic reflection generated classes are constantly loaded, resulting in the perm area is fully occupied.

Even more frightening is that different classloader even use the same class, but will load it, equivalent to the same thing, if there are n ClassLoader then he will be loaded n times. Thus, in some cases, this problem is largely considered to be without solution. Of course, there are a lot of classloader and a lot of reflective classes in fact not much.

Solve:

1.-xx:maxpermsize=16m

2. Replace with JDK. Like Jrocket.

Stack Overflow

Exception: Java.lang.StackOverflowError

Description: This is not much said, is generally recursive did not return, or circular call caused

Thread Stack Full

Exception: Fatal:stack size too small

Description: There is a limit to the space size of a thread in Java. This value is 1M after JDK5.0. The data associated with this thread will be saved in it. However, when the thread space is full, the above exception will appear.

Workaround: Increase the thread stack size. -xss2m. However, this configuration does not solve the underlying problem and depends on the part of the code that is causing the leak.

System memory is fully occupied

Exception: Java.lang.OutOfMemoryError:unable to create new native thread

Description

This exception is due to the fact that the operating system does not have enough resources to create this thread. When the system creates a thread, the operating system itself needs to allocate resources to create threads in addition to allocating memory in the Java heap. Therefore, when the number of threads to a certain extent, there may be space in the heap, but the operating system does not allocate resources to come, this anomaly.

The more memory that is allocated to the Java virtual machine, the less resources the system will have left, so the more memory is allocated to the Java Virtual machine when the system is fixed, the less the total number of threads the system can produce, which is inversely proportional to the relationship. At the same time, you can reduce the amount of space allocated to a single thread by modifying-XSS, or you can increase the number of threads produced in a total system.

Solve:

1. Redesign the system to reduce the number of threads.

2. Reduce the size of a single thread by-XSS when the number of threads cannot be reduced. So that more threads can be produced.