StackExchange.Redis超时问题求助（K8s环境ASP.NET 6应用）

环境背景 #

在Kubernetes集群中部署了Redis Server（先后试过6.2.5和7.0.10版本），应用基于默认aspnet:6.0（bullseye）镜像构建。应用稳定读写Redis近一年，但近两日频繁出现超时错误。

错误详情 #

StackExchange.Redis.RedisTimeoutException: Timeout awaiting response 
(outbound=188KiB, inbound=0KiB, 37574ms elapsed, timeout is 30000ms),
 command=ZADD, next: ZADD ADQ, inst: 0, qu: 0, qs: 126, aw: False,
 bw: SpinningDown, rs: ReadAsync, ws: Idle, in: 3949, in-pipe: 0, out-pipe: 0,
 last-in: 0, cur-in: 0, sync-ops: 0, async-ops: 28310, serverEndpoint: redis7.sf-app.svc:6379,
 conn-sec: 1583.67, mc: 1/1/0, mgr: 10 of 10 available,
 clientName: orchestration-317-qzp5s(SE.Redis-v2.6.96.30123), IOCP: (Busy=0,Free=1000,Min=16,Max=1000),
 WORKER: (Busy=345,Free=32422,Min=16,Max=32767), POOL: (Threads=345,QueuedItems=29523,CompletedItems=4409684),
 v: 2.6.96.30123

超时集中在某一未精确测量的时段内。

.NET计数器输出 #

% Time in GC since last GC (%)                                         0
    Allocation Rate (B / 1 sec)                                      227,048
    CPU Usage (%)                                                          0
    Exception Count (Count / 1 sec)                                        0
    GC Committed Bytes (MB)                                            2,790
    GC Fragmentation (%)                                                   1.406
    GC Heap Size (MB)                                                  2,392
    Gen 0 GC Count (Count / 1 sec)                                         0
    Gen 0 Size (B)                                                       384
    Gen 1 GC Count (Count / 1 sec)                                         0
    Gen 1 Size (B)                                                63,191,160
    Gen 2 GC Count (Count / 1 sec)                                         0
    Gen 2 Size (B)                                                 8,249,120
    IL Bytes Jitted (B)                                            1,533,858
    LOH Size (B)                                                   5,032,512
    Monitor Lock Contention Count (Count / 1 sec)                          0
    Number of Active Timers                                                9
    Number of Assemblies Loaded                                          174
    Number of Methods Jitted                                          19,209
    POH (Pinned Object Heap) Size (B)                             24,134,616
    ThreadPool Completed Work Item Count (Count / 1 sec)                  14
    ThreadPool Queue Length                                            3,611
    ThreadPool Thread Count                                              822
    Time spent in JIT (ms / 1 sec)                                         0

.NET追踪输出 #

1.  Threads                                                                   100%                0%
2.  (Non-Activities)                                                          99.96%              0%
3.  Task.ExecuteWithThreadLocal(class System.Threading.Tasks.Task&,class S    97.31%              0%
    ystem.Threading.Thread)
4.  ManualResetEventSlim.Wait(int32,value class System.Threading.Cancellat    97.06%              96.93%
    ionToken)
5.  Task.InternalWaitCore(int32,value class System.Threading.CancellationT    97.06%              0%
    oken)
6.  Task.SpinThenBlockingWait(int32,value class System.Threading.Cancellat    97.06%              0%
    ionToken)
7.  ThreadPoolWorkQueue.Dispatch()                                            96.98%              0%
8.  PortableThreadPool+WorkerThread.WorkerThreadStart()                       96.98%              0%
9.  ExecutionContext.RunFromThreadPoolDispatchLoop(class System.Threading.    96.95%              0%

已尝试的操作 #

• 增大Redis连接池PoolSize至200
• 设置ThreadPool.SetMinThreads
• 将应用工作负载减半
  以上操作均未解决问题。

补充信息：应用同时使用SignalR，Redis调用在Hub方法中执行；高频使用zadd、zpopmin、incr、incrby等异步命令。

排查建议 #

1. 检查Redis服务端状态 #

• 执行slowlog get查看是否存在慢查询，定位耗时较长的Redis命令
• 用info clients查看当前连接数，确认是否达到maxclients限制
• 监控Redis Pod的CPU、内存使用率，是否触发资源限制或OOMKill
• 检查Redis内存使用情况，是否达到内存上限触发键值淘汰策略

2. 排查集群网络问题 #

• 在应用Pod内执行ping redis7.sf-app.svc或tcpping redis7.sf-app.svc 6379，测试网络延迟与连通性
• 查看节点网络带宽使用情况，确认是否存在网络拥堵或带宽瓶颈
• 检查Kubernetes集群内的网络策略，是否有新增规则限制了应用与Redis的通信

3. 优化.NET线程池与客户端配置 #

• 确认ThreadPool.SetMinThreads在应用启动初期（如Program.cs开头）调用，且设置的最小值足够（建议根据CPU核心数调整，例如CPU核心数*4）
• 检查SignalR Hub方法中是否存在同步阻塞逻辑，避免耗尽线程池资源
• 升级StackExchange.Redis至最新稳定版本，旧版本（2.6.96）可能存在线程池或连接管理的已知问题
• 调整Redis客户端超时时间，结合业务场景评估是否需要适当延长，但需优先解决根本瓶颈

4. 分析应用流量与业务变更 #

• 对比近两日与历史的Redis命令QPS，确认是否有流量突增或新增高频操作场景
• 检查是否有业务代码变更，导致Redis调用逻辑出现异常（如批量操作增多、循环调用等）

5. 检查应用Pod资源配置 #

• 查看应用Pod的CPU、内存限制，确认是否因资源不足导致线程池任务无法及时调度
• 检查Kubernetes事件日志，是否存在Pod重启、节点调度等异常影响连接稳定性

内容的提问来源于stack exchange，提问作者Eldar