StackExchange.Redis Timeout performing 超时问题
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了StackExchange.Redis Timeout performing 超时问题,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1382字,纯文字阅读大概需要2分钟。
内容图文
![StackExchange.Redis Timeout performing 超时问题](/upload/InfoBanner/zyjiaocheng/885/159caf37d65e489da9e7e45ec2da3b4a.jpg)
最近在做的一个项目,用的.net core 2.1,然后缓存用的Redis,缓存相关封装是同事写的,用的驱动是StackExchange.Redis
version 2.0.571
,一直听说这个驱动并发情况下有TimeOut bug,项目开发差不多后,我压测了一下,简单的模拟30个用户持续访问某一个有用到缓存的查询接口,结果这么小的压力下超时异常出现:
Timeout performing GET my_141 (5000ms), inst: 30, qu: 0, qs: 20, in: 20320, serverEndpoint: 172.16.3.119:6379, mgr: 10 of 10 available, clientName: s-119, IOCP: (Busy=0,Free=1000,Min=1,Max=1000), WORKER: (Busy=120,Free=32747,Min=1,Max=32767), v: 2.0.571.20511(Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts))
后面是堆栈信息.....
蛋疼了很久,搜了很多文章,得到以下
解决方案
1、换掉,不用这个驱动( 可以看看.net core redis 驱动推荐,为什么不使用 StackExchange.Redis)
2、redis操作修改为全部异步&& ThreadPool.SetMinThreads(200, 200);
我用的第二种解决了问题,主要换驱动也可能遇到坑;还有时间成本问题;
原因简析
我们看到以上的异常信息当中有这么一段:
IOCP: (Busy=0,Free=1000,Min=1,Max=1000),
WORKER: (Busy=120,Free=32747,Min=1,Max=32767),
意思是当前繁忙的WORKER 线程有120个,而系统“要由线程池根据需要创建的新的最小工作程序线程数。”,也就是系统创建的工作线程数不足以满足redis的Get操作的繁忙线程的需求,导致部分Get操作的线程堵塞超时了;
所以我们把“最小线程workerThreads” 修改为200解决问题;
内容总结
以上是互联网集市为您收集整理的StackExchange.Redis Timeout performing 超时问题全部内容,希望文章能够帮你解决StackExchange.Redis Timeout performing 超时问题所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。