Redis命令执行慢原因分析与解决方案
问题背景与现象
Redis客户端执行命令时间比较慢,超出预期。
原因分析
- 客户端与服务端网络延时比较长。
- 客户端与服务端之间以及Redis实例之间网络带宽过载。
- Redis数据节点上运行了其他耗CPU比较高的服务。
- 客户端连接池配置不合理。
- Redis中使用了keys * 等全库扫描的命令。
- Redis数据库里面存在大key,大value。
- Redis的key存在集中过期或者删除大量key的情况。
- Redis最大内存配置超过10G,并且使用率超过10G。
- Redis内存使用率接近100%。
- Redis开启了AOF持久化(默认不开启)。
解决办法
- 可能原因一:
客户端与服务端网络延时比较长。
排查/解决思路:
长ping检查客户端与服务端之间的,响应时间越小越好。
- 可能原因二:
客户端与服务端之间以及Redis实例之间网络带宽过载。
排查/解决思路:
- 访问Redis前对数据进行压缩。
- 增大带宽。
- 可能原因三:
Redis数据节点上运行了其他耗CPU比较高的服务。
排查/解决思路:
建议Redis单独部署,不要和其他服务混合部署到一台服务器上面。
- 可能原因四:
Redis最大内存配置超过10G,并且使用率超过10G。
排查/解决思路:
Redis最大内存不应超过10G,超过10G时建议进行扩容。
- 可能原因五:
Redis开启了AOF持久化(默认不开启)
排查/解决思路:
建议默认不开启aof持久化。
- 可能原因六:
Redis内存使用率接近100%
排查/解决思路:
建议扩容。
- 可能原因七:
客户端连接池配置不合理。
排查/解决思路:
Redis客户端会使用连接池方式缓存Redis连接,当连接池配置不合理的时候,会导致客户端连接时获取不到足够的连接资源而等待,导致查询慢的现象。
主要涉及的连接池配置如下表所示,可通过qps等进行简单评估。
参数名
含义
默认值
使用建议
maxTotal
连接池中最大连接数
8
最大连接数 > (Redis qps峰值) / 单条命令耗时
maxIdle
连接池中允许最大空闲的连接数
8
建议和maxTotal保持一致
minIdle
连接池中确保最少空闲的连接数
0
最少连接池 = (Redis qps 平均值) / 单条命令耗时
timeout
连接和读写超时时间
-1,不超时
建议:1000 – 5000 ,可根据业务具体调整,不建议取默认值
blockWhenExhausted
当连接池耗尽后,调用者是否需要等待
true
建议使用默认值
maxWaitMillis
当连接池耗尽后,调用者的最大等待时间,单位是毫秒,只有参数blockWhenExhausted设置为true,此参数才会生效
-1,用不超时
建议:1000 – 5000,具体可根据业务调整,当发现报错时,建议调整maxTotal和maxIdle
numTestsPerEvictionRun
做空闲资源检测时,每次的采样数
3
可根据自身应用连接数进行微调,设置为-1,对所有连接做空闲检测,JedisPoolConfig中的配置为-1
- 可能原因八:
Redis中使用了keys * 等全库扫描的命令。
排查/解决思路:
Redis 使用全库扫描的命令会导致Redis查询慢的现象。全库扫描的命令如下表所示:
命令
含义
代替命令
KEYS *
列出当前实例里面所有的key
scan、sscan、hscan、zscan
FLUSHALL
删除当前实例所有key
/
FLUSHDB
删除当前实例对应db的key
/
- 可能原因九:
Redis数据库里面存在大key,大value。
排查/解决思路:
可使用redis-cli -h 10.244.225.243 -p 22400 –memkeys或者redis-cli -h 10.244.225.243 -p 22400 –bigkeys查询当前实例中占用内存超大的key以及占用大小。可根据具体业务进行整改。
- 点赞
- 收藏
- 关注作者
评论(0)