在今天上午的时候,突然收到大量的sentry报错,都是关于redis连接超时的警告。
首先想到的是去查看redis的监控,发现那个时间段,redis的请求数剧增,cpu使用率和带宽都陡增双倍。
到目前为止,可以看到redis的压力确实上来了。
随之,阿里云也给我们发来告警,说redis连接超时,导致主从切换。
于是,我们推测是程序的访问量剧增,接口中都又依赖redis,导致访问redis的请求等陡增。
当然,至于为什么会发生,是不是就是redis出问题了呢?最后又应该怎么调整?
是调整程序,还是加大redis的配置?
从监控大盘能看到的信息有:httpq qps高达17k~18k,jvm节点的内存和gc等没有任何异常,毫无压力。但是redis访问却超时。(程序设置连接redis的超时时间为3秒)
由于我们缺少对redis客户端的连接监控,从上图arms的redis监控可以看出,它也缺乏对lettuce外的监控。
所以说,我们只能从阿里云的cloudDBA,从dba的角度,反向去看连接上来的实例会话数。
推荐大家安装这块日志聚合工具,可以定制其监控报警。我们便是因为收到sentry报警,才及时知晓线上有什么故障的。
下面是摘自sentry的主要报错信息:
换句话说,默认情况下,我们使用的redis客户端只会创建一个连接。
总结:lettuce连接redis,只会创建一个连接。
当我们使用springboot框架的时候,你只要看spring-boot-autoconfigure.jar的实现。
org.springframework.boot.autoconfigure.data.redis.JedisConnectionConfiguration
配置RedisProperties.Pool赋值给JedisPoolConfig。
顺着代码往后看:
所以,只需要看类org.redisson.config.SingleServerConfig的成员变量以及构造函数。
- setConnectionMinimumIdleSize(5) 设置了连接池的最小空闲连接数为 5
- setConnectionPoolSize(10) 设置了连接池的最大连接数为 10
- setThreads(10) 设置了 Redission 使用的线程数
- setNettyThreads(2) 设置了 Netty 使用的线程数
Redission 使用线程池来处理异步操作,其中的线程数由 threads 配置项控制。较多的线程可能导致较多的连接。
总结:由于我们在使用redission的时候,采用的是默认值,所以连接池的最小连接数为24,这也趋近前文redis的客户端实例监控的数量(27)。
也可以说,之所以和其他服务相比,占用更多的连接,就是redission配置项使用的默认值所导致。
jvm程序的内存和gc没有变化,在接口访问量陡增的情况下,我们根据目前得到的信息,决定修改程序代码redission的配置。
也就是说,减少程序对redis服务器的并发请求,至少不会让redis服务器的压力陡增。
一味地增加redis配置当然不可取,因为我们的redis配置已经是很高了。
服务只是让redis的压力上升了,并不是会让得redis连接超时且切换了主从。
再说下去就是阴谋论了,水平有限,从目前获取到的信息看,只能把程序本来存在的旧问题给修复好,后期再看监控对比吧。
到此这篇redis连接数配置(redis 连接数)的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章,希望大家都能在编程的领域有一番成就!版权声明:
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符,请将相关资料发送至xkadmin@xkablog.com进行投诉反馈,一经查实,立即处理!
转载请注明出处,原文链接:https://www.xkablog.com/rfx/76025.html