Jvm gc Optimization-increase Eden Space to improve performance

Origin

The online version of Tomcat is upgraded to 7.0.52, And the JVM FullGC frequency conversion of some applications is complicated. During the peak period, the number of socket connections and Cpu usage increase dramatically.

Ideas

The idea is that the Tomcat code should be correct. The problem may be that the application code is upgraded, or the environment is changed. In short, the priority of Tomcat is at the end.

First, the application's heap dump is analyzed as follows:

Jmap-dump: format = B, file = path pid

Using the Heap Analyser analysis from IBM, we found that the RpcInvocation object called by dubbo rpc and the SimpleForEachIterator object of taglibs occupy a large part of the memory.

Normally, these two types of objects should be quickly recycled. How can they occupy such a large amount of memory? Are there other objects that reference them and cannot be released?

After careful analysis, we found that all RpcInvocation objects are root refer objects, that is, root objects. Normally, root objects can be recycled quickly. Why are there so many objects in the memory?

Check the JVM parameters of the application:

-Xms2g -Xmx2g -Xmn256m -XX:SurvivorRatio=8 -XX:ParallelGCThreads=8 -XX:PermSize=512m -XX:MaxPermSize=512m -Xss256k -XX:-DisableExplicitGC -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled

First, we found that the new generation of applications-Xmn256m is too small. Compared with the above, the RpcInvocation object occupies 226 M, and SimpleForEachIterator occupies M of memory.

Obviously, in the new generation, there is no way to put down so many objects. These objects must be put in the old space.

Since the RpcInvocation object and SimpleForEachIterator object can be recycled quickly, the idea is to trigger the online FullGC and check whether the object has been recycled.

Before triggering, use the jmap-histo pid to count the number of objects:
34: 136762 4376384 com. alibaba. dubbo. rpc. RpcInvocation
129: 16345 392280 org. apache. taglibs. standard. tag. common. core. ForEachSupport $ SimpleForEachIterator
After the Full GC is triggered using jmap-histo: live <pid>:
294: 625 20000 com. alibaba. dubbo. rpc. RpcInvocation
495: 292 7008 org. apache. taglibs. standard. tag. common. core. ForEachSupport $ SimpleForEachIterator
The quantity is greatly reduced.

So the conclusion is obvious,Young generation has a small space. As a result, some objects that should be quickly recycled are stored in the Old generation, which leads to a rapid increase in the Old generation, frequent Full GC.

So I want to increase the size of the new generation and change the JVM parameter:

 -Xms2g -Xmx2g -XX:ParallelGCThreads=8 -XX:PermSize=256m -XX:MaxPermSize=512m -Xss256k -XX:-DisableExplicitGC -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled 

It is observed that PermSize actually only uses less than 200 M, and there is no need to set it to 512 M, which wastes memory. Therefore, it is changed to-XX: PermSize = 256 m-XX: MaxPermSize = 512 m.

In addition, the new generation's maximum limit-Xmn256m is removed. Because the default NewRatio is 2, except for the PermSize, the new generation accounts for about 1/3 of the memory, that is, about (2048-256)/3 = 597 M. It is more than doubled compared with the original one.

After the change was made online, it was observed that the growth of the Old Space was slow, and the number of FullGC times was greatly reduced. The time was 50 ms, and Yong GC was 10 ms, achieving the desired effect.

Simple GC Process Analysis

First, let's take a look at a GC model diagram, which is very vivid:

In short, we know enough about GC.

Most new objects are allocated on Eden Space. When Eden Space is full, container vor Space is used for collection. The YGC algorithm is fast.

After multiple times of YGC, the surviving objects will be moved to the Old Generation (old space). When the Old Generation is full, FGC will be performed and FGC is usually slow.

Permanent Space can be left empty if you allocate enough Space at the beginning.

We can draw some conclusions:

• Rationally reduce the number of objects in the old generation;
• The Old Space may keep increasing. Sometimes there is no way to prevent objects from entering the Old Space. Of course, some programs never execute FGC;
• Do you do your best to prevent objects from entering the old generation? Obviously not. If some objects exist for a long time in the new generation, the burden of YGC is obviously increased. Objects still alive after multiple times of YGC should obviously be placed in the Old Space.

Ideal GC/memory usage

To sum up, we can find that the ideal GC should be like this:

The growth of the Old Space is slow, the number of FullGC operations is small, and the FullGC time is short (in most cases, it should be within 1 second ).

Summary:

Add as few default parameters as possible. I agree with redna xelafx that configuring the default parameters does not help many people who want to optimize them.

GC optimization is a trade-offs process. If there is a loss, it is best to configure different parameters in multiple different instances and then compare them.

There are many command line tools or graphical tools that can be used to get twice the result with half the effort.

Refer:

Http://www.alphaworks.ibm.com/tech/heapanalyzer IBM Heap Analyser

Various traps of http://hllvm.group.iteye.com/group/topic/27945 JVM tuning "standard parameters,Released by redna xelafx and strongly recommended

Http://www.taobaotesting.com/blogs/2392 JAVA performance profiling 1--JVM memory management and garbage collection

Http://www.oschina.net/translate/using-headless-mode-in-java-se uses the Headless mode on the Java SE Platform