epc性能问题排查

现象：

    事件吞吐率不高，full gc频繁，差不多两次/s。gc日志：年轻代频繁内存分配失败，老年代报concurrent mode failure。老年代的垃圾收集器从CMS退化为Serial Old，所有应用线程被暂停，停顿时间变长。

排查思路：

    业务产生的对象太多，垃圾无法及时回收。没有足够的空间，导致频繁full gc

排查过程

1.打印gc 日志，并分析

    -XX:+PrintGCDetails # 打印GC日志详情
    -XX:+PrintGCTimeStamps # 打印每次触发GC的时间
    -Xloggc:/capaa/gc.log

 

 

2.查看业务日志，观察有没有严重的队列阻塞或者队列被打满的情况，数据入库逻辑是否正常

    

    kafka获取消息 放入
    tailf /data/epc/log/svc_epc.log | grep ' writer queue size' | grep 'NoMergeQueue'
    上面传入到这里
    tailf /data/epc/log/svc_epc.log | grep ' writer queue size' | grep 'droolsQueue'
    上面传到入库队列
    tailf /data/epc/log/svc_epc.log | grep ' writer queue size' | grep 'clickhouseoutputLogon'

 

3.free  -h有效内存空间，iostat 查看io

 

 4.调整cms垃圾回收线程数-XX:ParallelGCThreads=5 

 

5.调整老年代  cms 垃圾收集器的垃圾回收阈值：

    -XX:+UseCMSCompactAtFullCollection （空间碎片整理）
    -XX:CMSFullGCsBeforeCompaction=n

 

6.垃圾产生速度超过清理速度

    晋升阈值过小；
    Survivor空间过小，导致溢出；
    Eden区过小，导致晋升速率提高；

 

 

小结：

1.io密集型：jvm老年代调大。因为io很慢，对象存活时间很长，多次monier gc之后，对象很容易进入老年代。如果老年代太小，很容易触发full gc

2.cpu密集型：年轻代调大。因为cpu对象处理很快，产生的对象也很快，大部分对象都是朝生夕死。年轻代需要调大，让大部分对象在年轻代回收掉