标签：get OOM 代码 redis 业务 send increase nettyThreads 连接池
项目场景：
设备报警记录存储在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吧，去修改业务代码了。。。。。。
标签：get,OOM,代码,redis,业务,send,increase,nettyThreads,连接池 来源： https://blog.csdn.net/qq_42862247/article/details/121764145
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。