导致Redis超时(Timeouts)常见问题

因实际应用中出现经常 Redis 超时问题,StackExchange.Redis 在 Github 上 Timeouts 一文从多个方面进行分析,并提供相应的解决方案, 为方便日后再次出现该问题时快速查阅,特写下本文作为技术笔记,同时给英文不太好的程序员(媛)提供参考。

导致Redis超时(Timeouts)常见问题

对于使用过 StackExchange.Redis 的程序员(媛),经常碰到类似于以下的异常:

Timeout performing GET keyName, inst: 1, mgr: ExecuteSelect, err: never, queue: 2, qu: 2, qs: 0, qc: 0, wr: 0, wq: 0, in: 0, ar: 0, clientName: computerName, IOCP: (Busy=0,Free=1000,Min=4,Max=1000), WORKER: (Busy=4,Free=32763,Min=4,Max=32767), Local-CPU: unavailable (Please take a look at this article for some common client-side issues that can cause timeouts: https://github.com/StackExcha…

即 Redis 执行超时,原因可能为以下几个方面的问题:

1、是否被网络、CPU 或内存(RAM)的限制?

验证客户端和搭建 Redis-Server 的服务器支持的最大带宽是多少。如果有些请求(request)被带宽限制,则它们消耗更长时间才能完成,从而可能导致超时。同样,验证是否被客户端或服务器上的 CPU 限制——这将导致请求等待 CPU 时间,从而超时。 还有更容易被忽略的情况,当 Redis 数据量超过分配的内存(RAM)限制时,发生 Redis 锁死,导致超时。

2、是否有命令(command)在 Redis 服务器上处理时,消耗很长时间?

可能有一些命令需要花费很长时间才能在 Redis 服务器上处理,导致请求超时。 长时间运行命令的例子有 mget 大量的键、keys* 或写得不好的 lua 脚本。 您可以运行 SlowLog 命令查看是否有请求花费比预期更长的时间。 关于命令的更多细节可以查看 这里

3、在向Redis发出的几个小请求之前是否有大量请求超时?

错误消息中的参数 “qs” 告诉您有多少请求从客户端发送到服务器,但尚未响应。 对于某些类型的加载,您可能会看到该值(qs)不断增长,因为 StackExchange.Redis 使用单个 TCP 连接,并且一次只能读取一个响应。 即使第一个操作超时,它也不会停止向(或从)服务器发送数据,其他请求也会被阻塞,直到完成为止, 从而导致超时。 一个解决方案是通过确保 redis-server 满足工作负载的足够大的缓存,并将大值分割为更小的块,来最小化超时机会。 另一个可能的解决方案是在客户端中使用 ConnectionMultiplexer 对象池,并在发送新请求时选择“最少加载” ConnectionMultiplexer, 这将防止单个超时导致其他请求也超时。

4、在超时异常中,是否看到大量繁忙或繁忙的工作线程?

让我们先来了解线程池增长的一些细节:

CLR 线程池有两种类型的线程 —— “工作线程”和“ I/O 完成端口”(I/O Completion Port,又名 IOCP )线程。

  • 工作线程用于类似于处理 Task.Run(……)或 ThreadPool.QueueUserWorkItem(……)方法的东西。 当工作需要在后台线程上发生时,这些线程也被 CLR 中的各种组件使用。
  • 当异步 IO 发生时(例如从网络读取),使用 IOCP 线程。

线程池根据需要(无任何调节)提供新的工作线程或 I/O 完成线程,直到达到每种线程类型的“最小值”设置。 默认情况下,最小线程数设置为系统上的处理器数。

一旦现有(繁忙)线程的数量达到“最小”线程数,线程池(ThreadPool)将调节以每 500 毫秒向一个线程注入新线程的速率。这意味着,如果你的系统需要一个 IOCP 线程的工作突发(burst of work),它会很快处理这个工作。 但是,如果工作突发超过配置的“最小”设置,则在处理一些工作时会有一些延迟,因为线程池会等待发生两种情况:1、现有线程可以自由处理工作; 2、现有线程没有空闲 500ms,因此创建一个新线程。

基本上,这意味着当繁忙线程的数量大于最小线程时,您可能在应用程序处理网络流量之前消耗 500ms 延迟。 此外,重点注意,当现有线程保持空闲超过 15 秒(基于我记住的),它将被清理,这个增长和收缩的周期可以重复。

如果我们查看 StackExchange.Redis(build 1.0.450 或更高版本)中的错误消息,您将看到它呈现当前线程池的统计信息(请参阅下面的 IOCP 和 WORKER 详细信息)。

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,

queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,

IOCP: (Busy=6,Free=994,Min=4,Max=1000),

WORKER: (Busy=3,Free=997,Min=4,Max=1000)

在上面的例子中,你可以看到,对于 IOCP 线程有6个忙线程,系统配置为允许 4 个最小线程数。 在这种情况下,客户端可能会看到两个 500 毫秒的延迟,因为 6 > 4。

请注意,如果 IOCP 或 WORKER 线程的增长被节制,StackExchange.Redis 会命中超时。

建议:鉴于上述信息,建议将 IOCP 和 WORKER 线程的最小配置值设置为大于默认值的值。 我们不能一刀切地指导此值应是多少,因为一个应用程序的适当值,对另一个应用程序将会太高或太低。 该设置也会影响复杂应用程序的其他部分性能,因此您需要根据您的特定需求调整此设置。 一个较好的初始值是 200 或 300,然后根据需要进行测试和调整。

如何配置此设置:

  • 在 ASP.NET 中,使用 “minIoThreads” 配置,设置 machine.config 文件中的

配置元素。 如果您在 Azure WebSites 内部运行,则此设置不会通过配置选项显示。 您可以通过 global.asax.cs 中的 Application_Start 方法以编程方式设置(参见下文)。

重要说明:此配置元素中指定的值是按每个核心设置。 例如,如果你有一个 4 核心的机器,并希望你的 minIthreads 运行时设置为 200,你将使用 <processModel minIoThreads =“50”/> 进行设置。

  • 在ASP.NET之外,使用 ThreadPool.SetMinThreads(……) API。
    原文作者:me860
    原文地址: https://segmentfault.com/a/1190000019990002
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞