Ji, an online tuning cms

JAVA is also an analysis of past performance tuning, there have been the following case:

1. JVM outOfMemory, mainly using jmap dump out hprof, were analyzed using MAT

2. JVM outOfMemory, use jmap dump out hprof, jhat use to identify abnormal memory object

3. JVM tuning, running a month after crash

4. JVM tuning, according to the sampling JFR, where consumption performance analysis, how to optimize the high frequency of the performance cost.

Etc. Other (such as multi-threaded lock contention due to performance degradation, etc.).

This time the case is more interesting, so recorded.

 

First description of this phenomenon is the tuning of this (not the screenshot):

1. The process is a monitor MQ, for memory computing, storage to the application of redis

2. during peak periods there will be several CMS, not continuous, so several times every hour.

3. old district according to the monitoring, you can see only use the 30 ~ 40M space, and after the occurrence of old has been steadily cms

4. metaspace slow growth to 60M, about ccs to 6M (metaspace is jdk1.8 only)

The investigation process is as follows:

1. The first review under the cms trigger conditions:

a) metaspace space satisfies a certain condition

b)system.gc

c) the new generation of promotion failure (particularly conditions are relatively complex, whether old region substantially to compare the available space to accommodate promotion size)

d) Fullgc downgrade

e) old region satisfies the greater than cms 50%, (not precise enough, this reference to a series of formulas)

Under f) CMSClassUnloadingEnabled circumstances, it may also trigger CMS

2. The idea of ​​investigation

a) First old district did not meet the 50%, indicating that not because of lack of space caused by the Older Generation, also should not be caused by the new generation of promotion

You may have reasons:

1) issue metaspace space

2) fullgc downgrade

3）System.gc

4) other unknown reasons

2.1 for troubleshooting problems metaspace process is as follows

a) 使用jinfo -flags pid | grep Metaspace

b) Use jstat -gc pid can see the changes metaspace space

c) Because metaspace directmemory actually use, rather than heap space, and then evaluated our actual cms trigger law and metaspace curve does not overlap

Thus doubt, there is no association.

Therefore, to write a piece of code to simulate

package gc;


import javassist.CannotCompileException;
import javassist.ClassPool;
import javassist.CtClass;
import javassist.NotFoundException;

import java.io.IOException;

public class GcMetaspace {

    //one simple jvm using default parameters for jvm.
    //use -Xmx64m -Xms64m -Xmn16m -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseConcMarkSweepGC
    public static void main(String[] args) throws IOException, CannotCompileException, NotFoundException {

        ClassPool classPool = new ClassPool(true);
        classPool.insertClassPath(".");
        for(int i=0;i< 23950;i++){
            CtClass clazz = classPool.makeClass("cn.lykm.SubType"+i);
            Class toClass= clazz.toClass();
            System.out.println("processing is " + toClass.getName());
        }
        System.out.println("finish ");
        System.in.read();
    }
}

If it is found that gc metaspace caused, indeed cms, but also trigger Fullgc, but depending on the application to judge, but also more regular.

Thus excluding Metaspace suspects

2.2 Fullgc downgrade

gc.log in no Fullgc words, there is no similar gc cause analysis. Thus excluding

2.3 System.gc

This log is also no relevant content, but also really easy to turn off, use -XX: + DisableExplicitGC to

2.4 Other

First enable -XX: + UseCMSInitiatingOccupancyOnly reduced cms trigger condition. Then observation