纪一次线上cms调优

过去也有对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 触发条件。再进行观测

猜你喜欢

转载自www.cnblogs.com/lykm02/p/11361043.html