Redis client 链接池配置不当引起的频繁 full gc

栏目: 数据库 · 发布时间: 6年前

现象

笔者负责的一个RPC服务就是简单的从Redis Cluster中读取数据,然后返回给上游。理论上该服务的对象大部分都应该是朝生夕死的,但是笔者查看gc log 的时候发现 age >=2 的对象还真有不少,甚至和age=1的对象差不多 。也就是说对象从eden晋升到 Survivor,之后的每次young gc 这些对象都是在 Survivor区域中移动,直到晋升到old 区域中。GC log 如下

Redis client 链接池配置不当引起的频繁 full gc

解决过程

因为只需要查看 Survivor中区域的对象,使用JVM自带的命令就不太合适。 笔者推荐用 唯品会开发 vjmap(他只支持CMS不支持G1) ,他能查看各个age的对象。笔者使用它查看age>=2的堆栈,堆内对象分布如下:

Redis client 链接池配置不当引起的频繁 full gc

其中最令人奇怪的就是deps.redis.clients.jedis.Jedis这个对象。因为这是链接Redis Cluster的对象,理论上 只要流量没有大的波动不会有大量的创建活动 。而且Jedis本身会持有 Sokect、OutputStream、byte[ ]等对象。

笔者找到了创建Jedis对象的地方进行埋点, 发现基本上每六分钟就会销毁和创建一批Jedis对象。因为知道Redis client 采用的是链接池的方式,就是看了一下GenericObjectPool代码,发现 有个定时任务检测对象。关键代码如下:

Redis client 链接池配置不当引起的频繁 full gc

Redis client 链接池配置不当引起的频繁 full gc

Redis client 链接池配置不当引起的频繁 full gc

Redis client 链接池配置不当引起的频繁 full gc

从上面代码我们看出,每隔一段时间,就是检测对象池里面对象,要是发现对象空闲时间超过一定时间,就会强制回收;然后又发现链接少于minIdle了,开始创建对象,以满足mindle。笔者所在公司封装Redis client 设置的检测轮询时间为6分钟。

上面问题已经找到了,解决就比较简单了。因为配置的 mindle过大导致,导致链接池里有大量空闲。项目中配置的mindle为32,修改为3测试 上线 观察。之后gc log如下:

Redis client 链接池配置不当引起的频繁 full gc

Redis client 链接池配置不当引起的频繁 full gc

Redis client 链接池配置不当引起的频繁 full gc

上图中dx04是优化之后的,dx03是优化之前的,从图中我们可以看出f ull gc次数由一周20次降为一周4次, young gc的时间平均下降了1.5ms左右(毕竟能减少对象在 Survivor中的移动

总结

作为项目的ower,我们一定要清楚了解业务特征。看看gc log是否符合业务特征应该呈现的gc log。如果不符合,使用合适的 工具 是查找原因,你一定有所收获。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

信息烟尘

信息烟尘

戴维·申克 / 黄锫坚 / 江西教育出版社 / 2002 / 14.50元

今天,我们被大量的信息淹没了:传真、电子邮件、各种新闻、消息和铺天盖地的广告,正如人们以前预示的那样:出现了一个令人鼓舞的信息时代,媒体专家兼网络评论员戴维·申克透过这些繁荣的表象,揭示了大量的无用的信息对我们造成的干扰,或者说,“信息烟尘”对我们个人的健康(包括精神上的和肉体上的)及对社会造成的极大危害。这《信息烟尘:在信息爆炸中求生存》宣告了“信息时代”神话的破灭。一起来看看 《信息烟尘》 这本书的介绍吧!

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具