【Azure Webjob + Redis】WebJob一直链接Azure Redis一直报错 Timeout Exception
问题描述
运行在App Service上的Webjob连接Azure Redis出现Timeout Exception。
错误截图:
参考Azure Redis对于超时问题的排查建议, 在修改Min Thread后,问题依旧。
流量突增和线程池配置
流量激增时,如果 ThreadPool 设置不佳,则可能导致对 Redis 服务器已发送但尚未在客户端上使用的数据的处理出现延迟。
System.TimeoutException: Timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)在上面的异常中,有几个需要注意的问题:
- 请注意,在
IOCP
部分和WORKER
部分,Busy
值大于Min
值。 这种差异意味着ThreadPool
设置需要调整。- 也可参看
in: 64221
。 此值表示客户端的内核套接字层收到了 64,221 字节,但应用程序尚未读取这些字节。 这种差异通常意味着,应用程序(例如 StackExchange.Redis)从网络读取数据的速度没有服务器向你发送数据的速度快。可以配置
ThreadPool
设置,确保线程池在流量激增的情况下快速扩展。
那么,这个情况如何来缓解呢?
问题分析
在增加 ThreadPool 配置后,问题并没有得到缓解。查看Redis服务端的运行状态,一切正常。在排除代码和服务端后,接下来就重点查看客户端状态。
查看App Service (Webjob) 的主体,它多个实例的CPU都有升高的情况,怀疑是当Webjob在某一个实例上运行的时候,消耗的CPU资源太高。因为Webjob的负载太高,一个实例的线程资源不够充足,所以需要多实例来处理。但是部署Webjob的时候,默认是单实例运行。
所以在部署的时候,需要手动设置为Multi Instance。
当修改WebJob的多实例,App Service上的Webjob不在报Redis Timeout Exception ( ... ... IOCP: (Busy=1,Free=999,Min=200,Max=1000), WORKDER: (Busy=576,Free=1471,Min=200,Max=2047) ... ... ) 。问题得到缓解!
参考资料
当在复杂的环境中面临问题,格物之道需:浊而静之徐清,安以动之徐生。 云中,恰是如此!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?