Redis 响应时间过长答案

【问题标题】：Redis is taking too long to respondRedis 响应时间过长
【发布时间】：2013-03-07 01:10:36
【问题描述】：

Redis 的响应延迟非常高，以至于在通过redis-cli 使用info 命令时无法输出信息。

该服务器处理来自大约 200 个并发进程的请求，但它不会存储太多信息（至少据我们所知）。当服务器响应时，info 命令报告使用的内存大约为 20 - 30 MB。

在服务器上运行top 时，在高响应延迟期间，CPU 使用率徘徊在 95 - 100% 左右。

这种行为的一些可能原因是什么？

【问题讨论】：

您的使用情况如何？有很多大的SORT 正在发生吗？你在生产代码中使用KEYS 吗？您是否在任何地方运行MONITOR？你的持久化策略是什么？
我们在这种情况下禁用了持久性。目前没有在任何地方使用任何KEYS 或MONITOR 命令。我们也没有SORTs，至少在我所知的范围内。此实例专用于rq(www.python-rq.org)。

【解决方案1】：

仅根据提供的数据很难提出解释，但这是我的猜测。我想您已经检查了明显的延迟源（与持久性相关的那些），没有 Redis 命令在 slow log 中占用 CPU，并且 Python-rq 腌制的作业数据的大小并不大。

根据文档，Python-rq 将作业作为哈希对象插入到 Redis 中，并让 Redis 使相关键过期（500 秒似乎是默认值）以摆脱作业。如果您有一些严重的吞吐量，那么在某一时刻，您将在 Redis 中有许多项目等待过期。与待处理的工作相比，他们的数量会很高。

您可以通过查看INFO 命令的结果中要过期的项目数来检查这一点。

Redis 过期基于惰性机制（在访问键时应用）和基于键采样的主动机制，在事件循环中运行（在伪后台模式下，每 100 毫秒）。重点是当主动过期机制运行时，无法处理任何Redis命令。

为避免过多影响客户端应用程序的性能，每次触发主动机制时仅处理有限数量的键（默认为 10 个键）。但是，如果发现超过 25% 的密钥过期，它会尝试使更多的密钥和循环过期。这就是这种概率算法自动调整其活动以适应 Redis 必须过期的密钥数量的方式。

当许多键要过期时，这种自适应算法会显着影响 Redis 的性能。您可以找到更多信息here。

我的建议是尝试通过设置过期时间来阻止 Python-rq 将项目清理委托给 Redis。无论如何，这对于排队系统来说是一个糟糕的设计。

【讨论】：

【解决方案2】：

我认为减少 ttl 不应该是 Redis 过期键时避免 CPU 使用的正确方法。

Didier 说得很有道理，Python-rq 的当前架构通过使用 key-expire 功能将清理工作委托给 Redis。当然，就像迪迪埃所说的那样，这不是最好的方法。（这仅在result_ttl大于0时使用）

然后，当您有一组密钥/作业的到期日期接近另一个时，问题应该会出现，并且可以在您创建大量作业时完成。

但是 Python-rq 在一个工作人员完成作业时设置过期键，

那么就没有太大意义了，因为key应该在时间之间分布，并且它们之间有足够的时间来避免这种情况

【讨论】：