这是一个创建于 809 天前的主题，其中的信息可能已经有所发展或是发生改变。
现象描述
最近一次上线使用了 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 类似问题，没有相似的，目前没有了排查头绪，求助一下。
7 条回复 • 2022-09-07 09:55:32 +08:00
 |
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 一般这时候我们按数据库连接超时或者锁行来排查（隔壁用了个运维给的虚拟机，线程数是假的）
|
Select Language