项目背景:
公司有块报警规则的模型,采用实时流storm处理技术,刚开始在规则数量和数据量小的情况下运行比较正常,但是随着业务量的增加,发现程序的运行效率越来越慢,一开始一条数据的处理时间1Ms,10天后,数据的处理性能变成8Ms,造成数据挤压,而且内存也一直递增,然后就采用传统的方案
增加并发,增加主机资源,基本上解决了数据挤压,但是运行效率越来越慢的问题一直没得到解决
9月份开始公司控运行成本,减少主机资源,主机由8C,32G缩减 8C 16G,然后遇到问题就是内存频繁报警,使用率过高,还出现过一次宕机。就出现了问题排查!
问题1:storm进程随着时间的运行越来越慢
-
时间1
- 时间2
- 时间3:
问题2:JVM内存越来越大
进程内存由3G到6.7G导致主机一直资源报警
问题排查
- 程序中和第三方交互资源瓶颈,比如redis,mysql等,经分析可以排除
- 程序中有大对象一直引用,无法释放,导致FullGC引起的 分析如下: jmap -dump:format=b,file=/data/heap-32.hprof 10507
jmap -dump:format=b,file=/data/heap-67.hprof 10507
分别导出进程3.2G和6.7G时的堆快照,通过jvisualvm 查看 对象大小 和线程 个数基本上一致,而且查看GC日志,很少有FullGC,基本上排除了FullGC的问题
3.难道是默认的GC回收器有问题?默认-XX:+UseParallelGC,JDK8以后推荐使用G1,可以减少程序的停顿时间,试试 -XX:+UseG1GC -XX:MaxGCPauseMillis=100,效果不明显,继续试试
4.难道是堆外内存,使用堆外内存,一部分是元数据区Metaspace,可通过参数设置,触发fullGC,还有一部分是 本地方法区的内存,百度查找-XX:MaxDirectMemorySize=256m不设置也会引起内存递增,加上后也没效果,那继续分析堆快照文件,
这块引起了我的注意,jdk.nashorn.internal.runtime.scriptloaded是什么??JDK8 引入的java中解析Js的加载器,原来程序中调用了eval,调用了 native方法导致内存增加,并且产生了很多class加载器引起的程序运行原来越慢~,那就下步验证
解决方案:每一条规则都生成一个Js function,然后缓存到本地,把变量以参数传递过去
demo如下:
然后经过包装兼容,上线运行:奇迹版的好了。
上线后的测试结果:
从原来的4毫秒左右降到了0.13毫秒 ,重点是整体资源利用率减少了50%,吞吐量提高了20倍
先写到这里。完工~