性能测试案例：redis获取不到连接池，Timeout waiting for idle object

Posted 2021-04-06 全栈测试笔记

↓↓↓ 如有疑问或者建议，请在文末留言 ↓↓↓

这是几个月前压测某项目登录接口时遇到的性能问题，虽然大家不一定会遇到，但是分析定位问题的思路还是可以参考一下。

一、问题现象

压测过程中，tps突然剧烈下降，且所有请求失败（下图绿线）

服务端错误日志，获取不到redis连接池（Could not get a resource from the pool），另外，从下图可以看到，当前jedis版本是2.9.1

获取不到连接，可能是这四种情况：
　　Timeout waiting for idle object
　　Pool exhausted
　　Unable to activate object
　　Unable to validate object

下图，表示等待空闲连接超时

二、分析定位

可以看到相关的配置

活动连接1000，连接满了

dump堆内存进行分析（此时压测已经停止）

根据文章开头的日志信息，搜索org.apache.commons.pool2.impl，然后双击下面的DefaultPooledObject类

进入实例

实例状态是ALLOCATED

ALLOCATED表示在使用中，压测结束后，虽然连接释放了，但是资源没归还

下面可以看到，dataSource为空

如果dataSource为空，就走else，说明只关闭了连接，资源没归还到队列中，后面的线程就获取不到空闲连接

可以看到，实例有很多

为什么会出现这种情况呢？

通过查看源码及官网，可以确定，这是2.9.1的bug，改为2.9.0就没报错了。

官网：https://github.com/xetorthio/jedis/pull/1918/commits/df1bffa3c77f4ede4c912f2c3e78b5c8857725e7

Move dataSource reset before connection returned to pool.

If datasource reset after the connection returned to pool, it might reset the datasource after it was allocated to another thread

三、总结

出现很多实例状态是ALLOCATED，dataSource为null的原因：

在多线程时，如果dataSource在连接释放后重置（根据代码逻辑可知：连接释放前，资源已经归还，但是未重置），可能在重置前，这个dataSource已经分配给另外一个线程了，此时重置，就把已经获取了这个dataSource的线程的dataSource重置了，这样就导致很多状态是ALLOCATED、dataSource值为null的实例，进而这些线程都只关闭了连接，而没有归还资源，最终导致获取不到连接，即文章开头的异常日志信息，这也印证了都是压测一段时间后才开始报错的现象。

另外，有些性能问题，还是需要一定的代码能力，而且，测试会代码是个趋势。

声明：封面图片来源于网络，如有侵权，请联系删除。

END

欢迎长按下图关注全栈测试笔记

性能测试等实战经验倾囊相授

↓↓↓ 如有疑问或者建议，请点击下方留言 ↓↓↓

推荐阅读

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

今天的苦逼, 是为了不这样一直苦逼下去!

走过路过，点个“在看”再走吧~