纪一次线上cms调优

时间：2021-07-10 14:29:44

过去也有对JAVA性能调优的分析，有过以下case：

1. JVM outOfMemory, 主要是使用jmap dump 出来 hprof,使用MAT进行分析

2. JVM outOfMemory, 使用jmap dump 出来hprof, 使用jhat 找出异常内存对象

3. JVM调优，程序运行1个月后崩溃

4. JVM调优，根据JFR 采样，分析性能消耗在哪里，如何优化高频的性能消耗。

等等其他(如 多线程竞争锁导致的性能下降等)。

这次的case 比较有意思，所以记录下来。

先描述本次调优的现象是这样的（无法截图）：

1. 进程是一个监听MQ， 进行内存运算，存储到redis的应用

2. 在业务高峰期会有若干次CMS， 不连续，每个小时都有那么几次。

3. old 区根据监控，可以看到只使用了30~40M 空间，并且cms发生后old一直平稳

4. metaspace 缓慢增长到60M， ccs 到6M左右（metaspace 是jdk1.8才有）

排查过程如下：

1. 先回顾下cms 触发条件：

a) metaspace 空间满足一定条件

b)system.gc

c) 新生代promotion failure(具体条件也比较复杂，基本是要比较old 区的可用空间是否可以容纳promotion size)

d) Fullgc 降级

e) old 区满足大于 cms 50%, (不够精确,这个要参考一系列的计算公式)

f) CMSClassUnloadingEnabled 情况下，也可能触发 CMS

2. 排查思路

a)首先old区并没有满足50%, 说明不是因为老生代空间不足引起的，也应该不是新生代promotion 引起的

那么可能得原因：

1） metaspace 空间的问题

2） fullgc 降级

3）System.gc

4）其他未知原因

2.1 对于metaspace 的问题排查过程如下

a) 使用jinfo -flags pid | grep Metaspace

b) 使用jstat -gc pid  可以看到metaspace空间的变化

c) 因为 metaspace实际上是使用的directmemory,而不是堆上的空间，再评估过我们的实际cms 触发规律和metaspace 曲线并无重叠

因而怀疑，并无关联。

因此，写了一段代码来进行模拟

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();

    }

}

发现如果是metaspace 引起的gc，确实是cms，不过也会触发Fullgc， 而且根据应用来判断，也比较规律。

因此排除Metaspace 嫌疑

2.2 Fullgc 降级

gc.log中并无Fullgc 字样，也没有类似的gc cause分析。因此排除

2.3 System.gc

这个日志也没有相关内容，而且确实也容易关闭，使用 -XX:+DisableExplicitGC 即可

2.4 其他

首先启用 -XX:+UseCMSInitiatingOccupancyOnly 缩减cms 触发条件。再进行观测

相关文章