一、背景

2023年03月08日，在某地域进行了线上压测，发现接口RT频繁超时，性能下降严重，P50 400ms+，P90 1200ms+，P99 2000ms+。

解释：压测中P50 P90 P99表示含义：

在性能测试中，P50、P90、P99等都是用来描述系统在不同负载下的性能表现的统计指标。这些指标通常用于描述系统响应时间的百分位数。

• P50，也称为中位数，意味着在所有请求中，有50%的请求响应时间小于或等于该值。这意味着，如果P50的响应时间是100毫秒，那么有50%的用户会在100毫秒或更短的时间内收到响应。
• P90，意味着在所有请求中，有90%的请求响应时间小于或等于该值。如果P90的响应时间是300毫秒，那么有90%的用户会在300毫秒或更短的时间内收到响应。
• P99，意味着在所有请求中，有99%的请求响应时间小于或等于该值。如果P99的响应时间是500毫秒，那么有99%的用户会在500毫秒或更短的时间内收到响应

细致排查发现其中重要的原因是，访问缓存响应时间竟然飙到了1.2s左右。

二、为啥Redis访问延时如此高？

我们简化下Redis访问流程如下：

可能性1：服务端问题？

我们Redis使用的

redis_amber_master_4xlarge_multithread 16C32G+480G SSD 规格，最大QPS参考值24w，最大连接数3w，配置还是非常豪华的。

如下，QPS以及Load在峰值请求阶段，都仍然处于低位。

可能性2：物理网络问题？

如下，请求远远没有达到机器带宽，不是瓶颈，另外单独看了网卡重传率等指标也都正常。

可能性3：客户端问题？

那么很大概率就是客户端自身问题了。我们把客户端详细放大如下：

①JVM FGC STW？

根据当时ARMS监控结果如下，虽然YGC次数与耗时有所上升，但没有发生FGC：

②JedisPool问题？

通过对内存Dump的分析，我们发现与JedisConnectionFactory相关的几个关键指标揭示了两个主要的问题：

1. maxBorrowWaitTimeMills的值过大：这一指标反映了获取连接的最大等待时间，其值高达1200毫秒。这个长的等待时间可能是由于在获取连接池的连接时产生的阻塞，从而导致请求处理速度减慢。
2. Redis连接的创建和销毁次数过多：具体来说，createdCount达到了11555次，而destroyedCount为11553次。这表明max-idle参数可能设置不合理（当检查到idle大于maxIdle时，会立即销毁该连接）。每个对象的创建都相当于一次TCP连接的创建，这会产生较大的开销。因此，当遇到脉冲式的请求时，会导致频繁的创建和销毁操作，进而影响整体性能。

需要特别提出的是，maxBorrowWaitTimeMills、createdCount和destroyedCount这几个度量信息是JedisPool对象持续维护的全局变量信息，只要JVM没有重启，这些信息就会一直存在。这就解释了为什么我们不需要在进行压力测试的峰值时获取内存dump，而可以在事后进行dump。

此外，如果要深入探索JedisPool参数的工作机制，就需要理解apache的ObjectPool2的机制。我曾经研究过ObjectPool，将来会单独写一篇文章来详细阐述和对比ObjectPool、ObjectPool2、JedisPool以及常常出问题的DruidPool的实现原理和差异。

总的来说，我们定位到的问题是JedisPool的行为异常导致的。

三、如何解决问题？

线上JedisPool实际参数

部分参数是由 redis.clients.jedis.JedisPoolConfig 继承而来

spring.redis.jedis.pool.max-active=100
spring.redis.jedis.pool.max-idle=16


spring.redis.jedis.pool.time-between-eviction-runs-millis=30000


spring.redis.jedis.pool.min-idle=0
spring.redis.jedis.pool.test-while-idle=true
spring.redis.jedis.pool.num-tests-per-eviction-run=-1
spring.redis.jedis.pool.min-evictable-idle-time-millis=60000

参数行为解析

• max-active：连接池的最大数量为100， 包括 idle + active. 注意， 这里spring.redis.jedis.pool.max-active被映射为了ObjectPool的maxTotal参数上。

• 连接池的最大空闲数量为16，即如果return时，idleObject>=16，则该对象直接被销毁。

• 启动后台线程，每30s执行一次，定时心跳保活与检测。

• 连接池最小空闲的连接数量为0。即corePoolSize为0，不会长期maintain一个固定的容量。

脉冲式请求引发的问题

我们把问题简化为如下序列，即可发现问题所在。在T2~T3内，84个对象创建，84个对象销毁，造成了极大的损耗。

期望的行为模式

由于线上环境，Redis服务器配置较高，为了能充分压榨性能，同时应对容器场景下典型的突发峰值，因此如下行为：

• 连接池的最大数量=连接池的最小数量=连接池的稳定数量，即不要临时去创建连接，防止等待过久。

这里的优化策略和Weblogic 在JDBC 连接池的优化策略是一样的， 我们一般定义是150到200个JDBC连接，而且最大 最小设置一样。

• 需要定时心跳保活与检测，及时删除掉超时/无效的连接。
• 不要因为idle时间过久而重建连接（只因为连接失效而重建）。防止无意义的大规模连接重建。

spring.redis.jedis.pool.max-active=500 // 线上稳定保有4台，4*500=2000，仍然远小于Redis规格支持的3w
spring.redis.jedis.pool.max-idle=50


spring.redis.jedis.pool.time-between-eviction-runs-millis=30000 // 定时心跳保活与检测


spring.redis.jedis.pool.min-idle=500 // 连接池的稳定数量
spring.redis.jedis.pool.test-while-idle=true //定时心跳保活与检测
spring.redis.jedis.pool.num-tests-per-eviction-run=-1 // 每次保活检测， 都需要把500个连接都检测一遍. 如果设置为-2， 则每次检测1/2比例的的连接.
spring.redis.jedis.pool.min-evictable-idle-time-millis=-1 // 不要因为idleTime大于某个阈值从而把连接给删除掉. 这样可以防止无意义的大规模连接重建。

四、效果验证

终于在20230413重新迎来了一波压测，流量模型与上次相同。结果如下：

• maxBorrowWaitTimeMills 下降比例接近 80%
• createdCount 也从之前的 11555次 下降到了 500次(即池子初始化的size)
• 业务侧整体性能也大幅提升，P50与P90均下降了将近60%，P99更是夸张地下降了70%。简直是amazing，完结撒花！~

转载信息：

作者丨寒亭

来源丨公众号：阿里开发者（ID：ali_tech）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn