性能文章>Redis client链接池配置不当引起的频繁full gc>

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

1年前
7477214

现象

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

image.png

解决过程

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

image.png

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

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

image.png

image.png

image.png

image.png

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

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

image.png

image.png

image.png

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

总结

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

请先登录,再评论

三冬暂就儒生学,千耦还从父老耕。——陆游《观村童戏溪上》

3月前

这个监控软件是啥,open-falcon?

1年前

为你推荐

从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
JVM 源码解读之 CMS 何时会进行 Full GC
前言 本文内容是基于 JDK 8在文章[ JVM 源码解读之 CMS GC 触发条件](https://heapdump.cn/article/190389) 中分析了 CMS GC 触发的
FGC实战:如何用Idea揪出开源组件调用System.gc导致频繁FGC
某天上午收到最近发布的一个服务频繁FGC的告警,这个服务只是给公司内部相关人员使用的,并非给互联网用户提供服务的系统。而且功能也比较简单,就是查看一些统计信息、报表数据、数据导出Excel等,访问量非
一个诡异的full gc查找问题
背景一个服务突然所有机器开始频繁full gc。而服务本身没有任何改动和发布记录。上线查看gc log日志,日志如下:从日志来看,每次发生full gc的时候都比较奇怪,主要有两点,第一、old区域和
构建企业级业务高可用的延时消息中台
业务场景剖析公司业务系统(比如:电商系统)中有大量涉及定时任务的业务场景,例如:实现买卖双方在线沟通的IM系统,为了确保接收方能够收到消息,服务端一般都会有重试策略,即服务端在消息发出的一段时间内,如
Redis client链接池配置不当引起的频繁full gc
现象笔者负责的一个RPC服务就是简单的从Redis Cluster中读取数据,然后返回给上游。理论上该服务的对象大部分都应该是朝生夕死的,但是笔者查看gc log 的时候发现 age =2 的对象还真
System.gc() 源码解读
介绍```System.gc()```,大家应该也有所了解,是JDK提供的触发Full GC的一种方式,会触发Full GC,其间会stop the world,对业务影响较大,一般情况下不会直接使用
记一次线上请求偶尔变慢的排查
前言最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章。 Bug现场这是一个偶发的性能问题。在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过