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