Unable to send command Try to increase ‘nettyThreads‘异常引起的OOM

项目场景：设备报警记录存储在redis里面，需要频繁访问redis取出报警时间对比，在项目运行一段时间后报错无法发送命令！尝试增加“nettyThreads”和/或连接池大小设置节点源：NodeSourceUnable to send command! Try to increase 'nettyThreads' and/or connection pool size settings Node

想要一百块

6514人浏览 · 2021-12-07 11:20:14

想要一百块 · 2021-12-07 11:20:14 发布

项目场景：
设备报警记录存储在redis里面，需要频繁访问redis取出报警时间对比，在项目运行一段时间后报错

无法发送命令！尝试增加“nettyThreads”和/或连接池大小设置节点源：NodeSource
Unable to send command! Try to increase 'nettyThreads' and/or connection pool size settings Node source: NodeSource

在这里插入图片描述
后续还导致了项目被oom终止运行

看报错信息类似是连接池大小的问题
在这里插入图片描述
然后修改连接池大小为500

后续还是报错也尝试过设置心跳都没有什么用说明应该不是配置参数的问题，换解决方案继续百度看到一篇比较有用的文章
Redisson RedisTimeOutException异常排查
但是我的本身就是同步的方法get然后就从get方面去入手
开始debug

在这里插入图片描述
添加了日志后发现有业务代码有逻辑问题频繁的去获取redis的get方法

在这里插入图片描述
把业务代码注释掉之后就正常了

突然发现自己好傻逼，因为业务代码也是本人写的可能因为之前数据量不多没有出现这个bug所以没有发现，当数据量一多的话就出现了这样的问题。

总结
我觉得从这个案例中收获了两点感悟：

现象并不那么可靠，不能头痛医头脚痛医脚。
先从怀疑自己的代码开始。

第一点，应该是个常识了，医生诊断的例子充分说明了这点。第二点，为什么要先从怀疑自己代码开始呢，简单来说就是应用的业务代码通常是测试和验证最不充分的代码。业务应用依赖的环境不论是硬件（主机、网络、交换机）的还是软件的（操作系统、JVM、三方库）这些通常都比业务代码经过更多地测试和广泛地应用验证，所以要先从怀疑自己开始，除非有非常明确地证据指向其他方面，个人经验大部分时候这都是找到问题的最短路径。

下次出现问题还是第一时间debug吧，去修改业务代码了。。。。。。