案例1: Dynatrace分析某财险承保系统内存泄漏问题
文档属性
此文档由东风微鸣编写。
未经许可,不得向个人或机构传阅或复制
修改记录
日期 | 作者 | 版本 | 修改记录 |
---|---|---|---|
2017/3/10 | 东风微鸣 | V1.0 | 创建文档 |
2017/10/29 | 东风微鸣 | V1.1 | 格式调整 |
审阅记录
审阅人 | 职位 |
---|---|
分发记录
拷贝No. | 姓名 | 单位 |
---|---|---|
1 | ||
2 | ||
3 | ||
参考文件
参考文件 |
---|
一 内存泄漏情况说明
今天使用Dynatrace检查发现callCenter的应用存在内存泄漏的情况。具体如下:
在过去6H内,OLD区内存使用量在持续增长,最终达到99.98%。且大部分OLD区内存无法GC。同时因频繁GC,导致JVM “STOP THE WORLD”的时间越来越大。严重影响业务性能。
对业务性能的影响如下图所示:
折线图是不包含挂起(stop the world)的响应时间,柱状图是包含挂起的响应时间。可以看到对业务的响应时间造成了一定的影响。
二 内存泄漏分析
使用Dynatrace分析结果如下:
- 确实存在内存泄漏。(相关资料可以在Dynatrace的下列路径中查看分析结果)
- 泄漏的实例主要是
ConcurrentHashMap”
和dubbo的LruCache
(ConcurrentHashMap
也是dubbo的LRUcache
调用的)如下图: -
泄漏的根源如下:
com.alibaba.dubbo.common.extension.ExtensionLoader
和com.alibaba.dubbo.cache.support.lru.LruCacheFactory
- LRU类的相关细节如下:
三 总结
综上,dubbo的LRU相关的类导致了内存泄漏。
可能的原因有:LRU缓存的cache size大小有问题;expire时间有问题;或者是相关cache一直存在引用,导致无法GC。
还请优化相关代码,避免出现内存泄漏的情况。