最近一次上线使用了 Reentrant Lock ,上限次日早上 9 点迎来流量高峰,出现较多 RedisTimeoutExcpetion:Command execution timeout for command(EVAL)...(省略的部分是 lua 的加锁和解锁逻辑部分),几天观察下来,一般会在 9:00-9:15 期间自动恢复,后面再也没有任何该搞错出现,待凌晨迎来流量低谷,次日 9 点该现象会再次出现。 伴随着该报错,能观察到的是 redis 节点的 client connection 会在短暂上升后,迎来一个平台阶段,这个阶段报错最多,后快速上升达到一个数值,此时报错也自动恢复。 下面 client connection 的曲线和报错量曲线
redisson 2.9.2 redis 为哨兵模式,1 主 2 从 应用 8 个节点,redis client 配置的最大线程数 100 ,即加起来为 800 ,最小空闲线程数 20 ,图中初始的 300 多,是因为其他应用共用了该 redis 集群。
翻了很多关于 redisson 类似问题,没有相似的,目前没有了排查头绪,求助一下。
1
ufan0 2022-09-07 00:14:56 +08:00
差点怀疑你是我的同事了,哈哈哈。
有检查过内存使用情况吗? 某个应用昨天出现了很多稀奇古怪的问题,后面发现是 Redis 内存爆了。 |
3
siweipancc 2022-09-07 09:24:17 +08:00 via iPhone
我没这么用过的场景(写崩了?),上锁是否有等待获取锁时间,如果有的话可以调低一点。
另一个不负责任的猜想:其他应用的客户端不支持非单机连接。 |
4
alexfarm OP @siweipancc 一般 9:15 恢复之后,QPS 还是这么大,但不会报错了,感觉和等待获取锁时间这些关系不大,不然应该会一直报错
|
5
siweipancc 2022-09-07 09:44:27 +08:00 via iPhone
@alexfarm 把对面 ban 了试一个早上:D ,我这边崩过,结果是有人没释放锁跟监听器
|
6
alexfarm OP @siweipancc 应该不是。。因为 share 资源的应用都是我们维护的,且还没到 redis 的配置的最大线程数啊
|
7
siweipancc 2022-09-07 09:55:32 +08:00 via iPhone
@alexfarm 一般这时候我们按数据库连接超时或者锁行来排查(隔壁用了个运维给的虚拟机,线程数是假的)
|