码迷,mamicode.com
首页 > Web开发 > 详细

关于GC(上):Apache的POI组件导致线上频繁FullGC问题排查及处理全过程

时间:2019-11-12 00:27:10      阅读:303      评论:0      收藏:0      [点我收藏+]

标签:问题:   excel   key   syn   scp   建议   pre   conf   资源   

某线上应用在进行查询结果导出Excel时,大概率出现持续的FullGC。解决这个问题时,记录了一下整个的流程,也可以作为一般性的FullGC问题排查指导。

1. 生成dump文件

为了定位FullGC的原因,首先需要获取heap dump文件,看下发生FullGC时堆内存的分配情况,定位可能出现问题的地方。

1. 1 通过JVM参数自动生成

可以在JVM参数中设置-XX:+ HeapDumpBeforeFullGC参数。
建议动态增加这个参数,直接在线上镜像中增加一方面是要重新打包发布,另一方面风险比较高

sudo -u admin /opt/taobao/java/bin/jinfo -flag +HeapDumpBeforeFullGC pid
sudo -u admin /opt/taobao/java/bin/jinfo -flag +HeapDumpAfterFullGC pid

也可以用HeapDumpOnOutOfMemoryError这个参数,只在outOfMemoryError发生时才dump。实测只有在fullgc完成时才会产生该文件,fullgc期间看不到。
此外还需要-XX:HeapDumpPath=/home/admin/logs/java.hprof这个参数来指定dump文件存放路径。

1.2 通过JDK工具生成

1.2.1 jmap

先获取java进程ID,再使用jmap进行dump。
注意,虚拟机上的jmap可能没有做路径映射,需要手动选择jdk路径下来执行

ps -aux | grep java
jmap -dump:file=test.hprof,format=b XXXX

1.2.2 通过jcmd

JDK7后新增的多功能命令,其中jcmd pid GC.heap_dump FILE_NAME的效果和jmap -dump:file=test.hprof,format=b pid一样。

1.3 JConsole

可以生成本机或远程JVM的dump。还有一些其他工具就不详细介绍了。

2. 下载dump文件

由于使用的是阿里云的服务器,可以直接将dump文件上传到OSS上通过公司内部工具来分析,或通过OSS再下载到本地。
设置OSSCMD:
操作命令 osscmd config --host=oss-cn-hangzhou-am101.aliyuncs.com --id=** --key=**
创建bucke:osscmd cb 000001
上传文件:osscmd put 1.txt oss://000001/
下载文件:osscmd get oss://000001/1.txt 1.txt

其他类型的Linux主机可以使用SCP命令,参考:Linux scp命令

3. 分析工具

通过dump文件来分析fullGC的原因,需要关注哪些类占用内存空间较多、不可到达类等。
由于使用的是公司内部工具Zprofiler和grace,详细的使用过程这里就不截图了。一些其他可用的工具和命令(参考Java内存泄漏分析系列之六:JVM Heap Dump(堆转储文件)的生成和MAT的使用):

  • jhat, JDK自带,使用jhat <heap-dump-file>生成网页,通过浏览器访问``查看
  • jvisualvm
  • Eclipse Memory Analyzer(MAT)
  • IBM Heap Analyzer

需要注意的是,只看dump文件有时还不能得到结论,因为占用空间大头的有可能是String、ArrayBlockingList这样的对象,而且内容可能是null或null对象的集合,无从排查。此时还要结合发生fullgc前后业务系统发生了什么动作来确定。如果有条件的话可以在日常环境或预发环境重现一下。
当然,如果内存中的空间消耗对象是特殊的类,就比较好排查了。

4. 分析和改进

具体情况具体分析。

4.1 本次排查的场景

查询DB中数据->在异步线程中通过poi转换成Excel->上传到OSS。

示例代码:

// 导出代码中将变量直接作为lambda表达式的值传入
List<XXData>  data = queryData(request);
SheetDownloadProperty property = sheetDownloadProperties.get(0);
property.setTotalCount(request.getQueryRequest().getPageSize());
property.setPageSize(request.getQueryRequest().getPageSize());
property.setQueryFunction((currentPage, pageSize) ->  data);
// 该组件会在线程池异步调用poi组件转换为excel、上传OSS、下载
asyncDownloadService.downloadFile(downloadTask);
private List<XXData> queryData(ExportRequest request) {
    //查询DB,略
}
// 查询方法
@FunctionalInterface
public interface PageFunction<T> {

    /**
     * 方法执行
     */
    List<T> apply(Integer currentPage,Integer pageSize);
}

4.2 dump文件分析

通过内部工具可见,fullGC前有三个占据内存较高的ArrayBlockingList,里面有大量的内容为null的Object。
技术图片

这三个ArrayBlockingList所属的中间件,虽然本身和业务流程没有关系,但是仍不能排除嫌疑。

4.3 尝试解决

4.3.1 方案1:poi相关解决方案

由于依赖了二方库poi,这个库的usermodel模式很容易引起fullGC,同时也怀疑是因为lambda表达式直接传了变量。
把poi的usermodel改为事件模式(https://my.oschina.net/OutOfMemory/blog/1068972)可以避免这个问题。
但是该功能是一个二次封装的三方包中的,同时其他引用该组件的应用fullgc频率并不高,没有采用这个方案。

4.3.2 方案2:中间件升级

持有大量null对象的中间件版本较低,且新版目前已不再维护,老版本的releas note虽然没有提到这条bug fix,有一定嫌疑。
该中间件初始化时会创建三个容量为810241024的ArrayBlockingList,和dump文件相符合。
同样是因为这个中间件是在三方包中封装,不方便直接该版本,同样没有采用这个方案。

4.3.3 方案3:增大堆大小

可以调整metaspace参数来实现,本次想找到代码中相关的线索来解决,未采用该方案。

4.3.4 方案4:业务代码修改

仔细观察了这段代码在其他系统的的实现,发现其他系统的lambda表达式是匿名方法,而不是直接传值,即:

property.setQueryFunction((currentPage, pageSize) ->  {
    // 查询逻辑, 略
);

怀疑是直接传变量进去导致的垃圾回收问题。更改到这种模式后,触发下载功能时,连续长时间的fullGC仍然时有发生,没有解决问题。

4.3.5 方案5:替换垃圾回收器

暂时能确定的原因是,公司中间件本身占用堆内存较多,运行poi增加了GC的频率。但是由于它们都在二方库的原因,不方便修改。
此时搜索到stackoverflow有关于poi反复GC的一个问题,和我的情况类似,也是反复GC但是仍然不能释放内存。有回复建议将GC回收器替换为G1GC,将默认的UseConcMarkSweepGC替换后效果明显,一次FullGC就可以完成回收释放,不会反复FullGC,如下图,20:30前的fullGC是CMS,持续时间长且反复进行;20:30后是替换后第一次触发excel转换下载,进行了多次下载,即使发生FullGC也只有1次,大大缓解了之前的问题:

技术图片

本次暂定只采用方案5。

G1GC在JDK9已替代CMS成为了正式的垃圾回收器,低版本JDK需要手动设置。具体需要设置的JVM参数:

-Xms32m
-Xmx1g
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC 
-XX:MaxHeapFreeRatio=15 
-XX:MinHeapFreeRatio=5

注意前两行一般应用都会设置,不要覆盖掉。最后两行需要视情况调整。另外,默认的-XX:+UseConcMarkSweepGC需要去掉。

使用G1GC时需要确认工作线程数是否和预期一致,不要太多,一般来说和CPU核数一致即可。出现非预期数目的原因可能是,镜像脚本指定核数时,直接按照物理机而不是虚拟机核数来生成。
查看方式是看gc日志:
技术图片
虚拟机设置核数的dokcker脚本示例:

export CPU_COUNT="$(grep -c 'cpu[0-9][0-9]*' /proc/stat)"

5. 其他

5.1 典型fullGC场景举例

  • 外部资源未释放,如将利用tair实现的分布式锁放在Map中,未做解锁
  • fastjson的反序列化异常抛出后没有处理
  • 框架固有缺陷,如本例apache的poi组件,使用usermodel模式做excel导出时,当操作比较频繁或有其他内存泄漏有可能造成
  • JVM的metaspace设置过小

5.2 core dump和heap dump

core dump是针对线程某一时刻的运行情况的,可以看到执行到哪个类哪个方法哪一行以及执行栈的;heap dump是针对内存某一时刻的分配情况的。

5.3 stackoverflow上关于poi内存占用问题的讨论:

简单摘译了一些,可以直接看原文。

  1. Java对堆内存分配是懒回收的,如果JVM不想这么做,即使运行Runtime.gc(),也可能什么也不做。sapiensl和Amongalen的回答
  2. 触发FullGC,并不是因为内存泄漏,仅仅是因为poi占用了太多的内存。Michael的回答

关于G1GC,会在后续文章中研究。

关于GC(上):Apache的POI组件导致线上频繁FullGC问题排查及处理全过程

标签:问题:   excel   key   syn   scp   建议   pre   conf   资源   

原文地址:https://www.cnblogs.com/wuyuegb2312/p/11799352.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!