infoRedis 的响应延迟非常高，以至于在使用命令时无法输出信息redis-cli。
该服务器处理来自大约 200 个并发进程的请求，但它不存储太多信息（至少据我们所知）。当服务器响应时，该info命令会报告大约 20 - 30 MB 的已用内存。
在服务器上运行top时，在高响应延迟期间，CPU 使用率徘徊在 95 - 100% 左右。
这种行为的一些可能原因是什么？
问问题
5750 次
2 回答
11
仅根据提供的数据很难提出解释，但这是我的猜测。我想您已经检查了明显的延迟源（与持久性相关的那些），没有 Redis 命令在慢速日志中占用 CPU ，并且 Python-rq 腌制的作业数据的大小并不大。
根据文档，Python-rq 将作业作为哈希对象插入到 Redis 中，并让 Redis 使相关键过期（500 秒似乎是默认值）以摆脱作业。如果您有一些严重的吞吐量，那么在某一时刻，您将在 Redis 中有许多项目等待过期。与待处理的工作相比，他们的数量会很高。
您可以通过查看INFO命令结果中要过期的项目数来检查这一点。
Redis 过期基于惰性机制（在访问密钥时应用）和基于密钥采样的活动机制，在事件循环中运行（在伪后台模式下，每 100 毫秒）。关键是当主动过期机制运行时，无法处理任何Redis命令。
为避免过多影响客户端应用程序的性能，每次触发活动机制时仅处理有限数量的键（默认情况下，10 个键）。但是，如果发现超过 25% 的密钥过期，它会尝试使更多的密钥和循环过期。这就是这种概率算法自动调整其活动以适应 Redis 必须过期的密钥数量的方式。
当许多密钥要过期时，这种自适应算法会显着影响 Redis 的性能。您可以在此处找到更多信息。
我的建议是尝试通过设置过期时间来阻止 Python-rq 将项目清理委托给 Redis。无论如何，这对于排队系统来说是一个糟糕的设计。
于 2013-03-07T19:47:47.223 回答
0
我认为减少 ttl 不应该是 Redis 过期键时避免 CPU 使用的正确方法。
Didier 说得很有道理，Python-rq 的当前架构通过使用 key-expire 功能将清理工作委托给 Redis。当然，就像迪迪埃所说的那样，这不是最好的方法。（这仅在 result_ttl 大于 0 时使用）
然后，当您有一组密钥/作业的到期日期接近另一个时，问题就会出现，并且可以在您创建大量作业时完成。
但是 Python-rq 在一个工作人员完成工作时设置过期键，
那么它就没有太大意义了，因为密钥应该在它们之间有足够的时间分布，以避免这种情况
于 2013-03-08T19:43:18.820 回答