导致Redis超时（Timeouts）常见问题

因实际应用中出现经常 Redis 超时问题，StackExchange.Redis 在 Github 上 Timeouts 一文从多个方面进行分析，并提供相应的解决方案， 为方便日后再次出现该问题时快速查阅，特写下本文作为技术笔记，同时给英文不太好的程序员（媛）提供参考，帮助大家更好的学习redis http://www.maiziedu.com/course/337/。
　　　对于使用过 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/StackExchange/StackExchange.Redis/tree/master/Docs/Timeouts.md)
　　即 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，你将使用 进行设置。
· 在ASP.NET之外，使用 ThreadPool.SetMinThreads（……） API。

文章来源：彭智勇


已有 0 人发表留言，猛击->> 这里<<-参与讨论


ITeye推荐

• —软件人才免语言低担保 赴美带薪读研！—