一次堆外内存泄露的排查过程-低调大师

一次堆外内存泄露的排查过程

2018-10-23 640

背景：车联网应用，高频的监控数据解析入库查询。涉及到的中间件包括OTS、KAFKA、REDIS、RDS、DUBBO、MaxCompute、DataHub等等。

表现：java堆内存呈现非常规律的锯齿状，YGC,FGC都是正常的表现。但是在top命令中JAVA进程使用的RES持续增长，涉及到车联网产品8个应用。部分应用（8G内存）连续运行2天就使用了将近80%的内存。部分应用运行大概一周后占用了80%内存。截图一个典型的内存占比增长和堆内存的变化曲线

排查的过程比较曲折，网上也翻阅了不少前人的经验。不过较多的都是一些特定的例子，并没有形成系统的方法。不过通过例子确实帮助找到几个主要的堆外内存泄露的坑。其中有一篇文章的方法思路跟我后来总结的较为接近https://www.liangzl.com/get-article-detail-5958.html 。可以借鉴。
我这里总结下核心的排查思路。
1：JAVA堆内存泄露排查，因为这里主要讲堆外内存泄露的问题。所以这里主要讲下工具方法然后直接贴图了。主要使用Eclipse的MAT（Memory Analyzer Tool）来分析dump文件。工具会给出堆内内存泄露的点，这些都是比较直接的。上图（本例里面使用了ScheduleX，使用了几个大的队列，并不是泄漏点）
2：堆外内存排查，这里直接把套路列出来，不赘述自己走过的弯路。

使用MAT的Histogram查找java.lang.ref.Finalizer（至于这个类是干啥的，可以自行百度）。如果这里能过滤出来上万的对象，那基本上这里一定存在着堆外内存泄露的点了（比如这里的Socket连接，通过List Objects--with outgoing reference）

一般你都可以通过reference对象一步步抽丝剥茧找到这个等待Finalizer队列回收的对象的相关属性，我就是通过这个定位到其中一个应用未使用数据库连接池，导致非常多的socket连接等待关闭，而socket连接肯定会使用到系统的读写缓存，自然进程就消耗了较多的堆外内存。

当然通过java.lang.ref.Finalizer我们还可能找到除socket连接之外的一些待释放资源，比如我就找到很多java.util.zip.Deflater（Inflater）对象。看了下他的代码，是重写了finalize的方法的，所以这里是个坑，高频的使用gzip解压缩得时候，就会有这个问题。而梳理我们的应用，我们使用的kafka在消息发送的时候选择了gzip的压缩方式，所以整个应用群在这部分内存泄露上存在着相同问题。将kafka的消息压缩方式改成snappy，解决了整个应用群80%的内存泄露问题。
前面讲到kafka的gzip消息发送配置导致了堆外内存泄露80%的问题，那剩下的20%的问题在哪里？一个是根据对应用的特点，比如我这边剩下的应用特别之处是使用了动态脚本语言，那就从这个点切入进去，这次百度没啥发现，试了google，发现这个问题
https://bugs.openjdk.java.net/browse/JDK-8197544 把这个当做怀疑点验证发现ScriptEngine.eval 方法存在着内存泄露的问题。因为开发人员使用了直接eval代码段的方式，每次处理的时候都是直接eval脚本。后来改成script function的调用方法，并且保证script的eval只执行一次，后续都是缓存这个engine然后invokeFunction传参。（这有点类似预编译之后调用的意思？）

上面是因为自己熟悉应用特点，所以针对性地去排查的动态脚本引擎的问题，假设我不知道这个特点，如果定位可能的问题，通过perf record，perf report去查看所有JNI的方法调用，也许这里能知道蛛丝马迹。比如这里的脚本引擎调用。
java.lang.ref.Finalizer较多的时候，也可以考虑调优下JVM的启动参数，我这里调整了下 -XX:-UseAdaptiveSizePolicy 关闭了JVM的动态内存尺寸调整，避免ED,S0,S1的动态调整，担心S0,S1太小会不会导致更多的对象进到老年区。

结论：通过java.lang.ref.Finalizer来查找等待系统回收的资源，这里是内存泄露重灾区。通过perf等工具查找可疑的JNI调用，通过对应用特点分析找到可疑的点。
最后附上一张调整后的对比图

微信关注我们

原文链接：https://yq.aliyun.com/articles/657160

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

JavaScript原型链和继承

1.概念 JavaScript并不提供一个class的实现，在ES6中提供class关键字，但是这个只是一个语法糖，JavaScript仍然是基于原型的。JavaScript只有一种结构：对象。每个对象都有一个私有属性：_proto_，这个属性指向它构造函数的原型对象（property）。它的原型对象也有一个属于自己的原型对象，这样层层向上只至这个原型对象的属性为null。根据定义null没有自己的原型对象，它是这个原型链中的最后一个环节。几乎所有的JavaScript中的对象都是位于原型链顶端的Object的实例。 2.基于原型链的继承 JavaScript对象是动态的属性“包”（指其自己的属性）。JavaScript对象有一个指向原型对象的链。当访问一个对象的属性时，它不仅仅在对象上搜寻，还会试图搜寻对象的原型，以及该对象原型的原型，依次层层向上搜索，直至找到一个名字匹配的属性或者到达原型链的顶端为止。在ECMA标准中，someObject.[[Prototype]]符号是表示指向someObject的原型。从ES6开始[[Prototype]]可以通过Object.getPr...

2018-10-24

628

近期需要画个某数据的地区分布，basemap安装成功后运行总是出错。Basemap 是Python环境下极好的数据可视化工具，但是随着新项目的推出以及维护期逐渐接近尾声，basemap也将逐渐退出江湖。于是就转而使用folium，geoplot和cartopy，这三个包目前都是在conda forge 通道安装。简单描述一下，具体介绍上官网：folium是d3.js上著名的地理信息可视化库leaflet.js为Python提供的接口，通过在Python端编写代码操纵数据，来调用leaflet的相关功能，基于内建的osm或自行获取的osm资源和地图原件进行地理信息内容的可视化，以及制作可交互地图。http://python-visualization.github.io/folium/index.htmlCartopy 是一个处理地理信息生成地图和其他地理信息分析的Python 包。Cartopy 依赖PROJ4, numpy，Matplotlib等。https://scitools.org.uk/cartopy/docs/latest/index.htmlgeoplot是一个高级的地理...

2018-10-25

1240

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。