• 记录一次线上fullgc问题排查过程


    某天,接到测试部门反馈说线上项目突然很卡,由于当前版本代码和上一版本相比就多了一个刚上线了一个5分钟1次的跑批任务,先关闭次任务后观察是否卡顿,并检查堆内存是否使用完造成频繁gc

    1.通过jmap命令查看堆内存中的对象

    2.生成当前堆快照文件并用mat工具打开(file->HeapDump)

    导出命令如下:

     ./jmap -dump:format=b,file=heap.dump 3920149

    发现是有一个任务线程创建了最多的对象,调整对应配置如下核心线程从1个改5个线程

    3.查看堆内存设置情况:

     ./jhsdb jmap --heap --pid  7853

    返回说明:

    1. MinHeapFreeRatio:最小堆空闲比例,表示堆中空闲空间的最小比例。默认值为40,表示堆中至少有40%的空间是空闲的。

    2. MaxHeapFreeRatio:最大堆空闲比例,表示堆中空闲空间的最大比例。默认值为70,表示堆中最多可以有70%的空间是空闲的。

    3. MaxHeapSize:最大堆大小,表示堆的最大可用空间。

    4. NewSize:新生代大小,表示新生代的初始大小。

    5. MaxNewSize:最大新生代大小,表示新生代的最大可用空间。

    6. OldSize:老年代大小,表示老年代的初始大小。

    7. NewRatio:新生代与老年代的比例,表示新生代与老年代的大小比例默认为2。

    8. SurvivorRatio:幸存者区与Eden区的比例,表示幸存者区与Eden区的大小比例。默认值为8,表示幸存者区的大小是Eden区大小的1/8。

    9. MetaspaceSize:元数据区大小,表示元数据区的初始大小。

    10. CompressedClassSpaceSize:压缩类空间大小,表示压缩类空间的初始大小。

    11. MaxMetaspaceSize:最大元数据区大小,表示元数据区的最大可用空间。

    12. G1HeapRegionSize:G1堆区域大小,表示G1堆区域的大小

    堆分为新生代和老年代 默认占比 1:2, 可以看到老年代占用使用过高,调整其大小,调整为3 使用参数为:

    -XX:NewRatio=3
    

    新生代分为eden区、From Survivor(S0区)、To Survivor(S1区) 默认占比8:1:1,,可以看的s区100%,调整为6

    -XX:SurvivorRatio=6
    

    其他调整为:

     -Xmx8192M 最大堆内存调整为8192M
    -XX:MetaspaceSize=256M 设置元数据区初始值256M
    -XX:MaxMetaspaceSize=512M 设置元数据区最大值256M
    -XX:MaxDirectMemorySize=256M 设置堆外内存256M
    -XX:PretenureSizeThreshold=11457280 设置对象超过11457280 字节直接进入老年代
    -XX:MaxTenuringThreshold=15 设置垃圾最大年龄15 超过这个就进入老年代
    -XX:+HeapDumpOnOutOfMemoryError 打印OOM
    -XX:HeapDumpPath=./logs/dump.hprof dump文件

    4.调整后重启观察gc情况发现明显好转从600多次fgc到12次fgc,而且12次均为启动时就触发

    ./jstat -gcutil 7853 5000 5

    返回说明:

    • S0:Survivor 0区的使用率,表示Survivor 0区已使用的百分比。
    • S1:Survivor 1区的使用率,表示Survivor 1区已使用的百分比。
    • E:Eden区的使用率,表示Eden区已使用的百分比。
    • O:老年代的使用率,表示老年代已使用的百分比。
    • M:元数据区的使用率,表示元数据区已使用的百分比。
    • CCS:压缩类空间的使用率,表示压缩类空间已使用的百分比。
    • YGC:Young Generation垃圾回收的次数,表示Young Generation垃圾回收的次数。
    • YGCT:Young Generation垃圾回收的总时间,表示Young Generation垃圾回收的总时间。
    • FGC:Full GC的次数,表示Full GC的次数。
    • FGCT:Full GC的总时间,表示Full GC的总时间。
    • CGC:Concurrent Mode Failure的次数,表示Concurrent Mode Failure的次数。
    • CGCT:Concurrent Mode Failure的总时间,表示Concurrent Mode Failure的总时间。
    • GCT:垃圾回收的总时间,表示垃圾回收的总时间。

    参数解析

    5.打印gc.log定位增加参数

     -XX:+PrintGCDetails  -Xloggc:./logs/gc.log

    发现如下日志:

    6.定位system.gc的具体位置

    下载 https://arthas.aliyun.com/arthas-boot.jar

    启动后选择本地项目如下:

    访问arthas 的web界面

    可以发现是由于项目中引入领英的paldb的问题要如何解决呢?

    方法1:

    -XX:+DisableExplicitGC

    该参数将使JVM完全忽略系统的GC调用(不管使用的收集器是什么类型),国产欧拉系统设置了不生效,centos7系统机器设置正常

    方法2:

    -XX:+ExplicitGCInvokesConcurrent

    该参数启用后JVM无论什么时候调用系统GC,都执行CMS GC,而不是Full GC。

    7.再次观察gc

    至此卡顿问题解决!

  • 相关阅读:
    c# 画球
    Netty笔记
    vue3学习(十一)--- v-model
    【JMeter接口测试工具】第二节.JMeter基本功能介绍(上)【入门篇】
    iOS NSFileManager获取设备硬盘剩余可用容量不准确问题
    后端微服务项目中出现的问题整理2022年11月
    4.k8s:cronJob计划任务,初始化容器,污点、容忍,亲和力,身份认证和权限
    《痞子衡嵌入式半月刊》 第 93 期
    uniapp 使用 z-paging组件
    vue父页面与子组件之间的生命周期
  • 原文地址:https://blog.csdn.net/u012440725/article/details/133785004