Jua*_*oto 5 concurrency resources cpu-usage server-load redis
使用Redis经历了非常高的响应延迟,在使用info命令时无法输出信息redis-cli.
此服务器处理来自大约200个并发进程的请求,但它不存储太多信息(至少据我们所知).当服务器响应时,该info命令报告使用的内存大约20 - 30 MB.
在top服务器上运行时,在高响应延迟期间,CPU使用率徘徊在95-100%左右.
造成这种行为的可能原因是什么？
仅根据提供的数据提出解释是困难的,但这是我的猜测.我想你已经检查了明显的延迟源(与持久性相关的延迟源),没有Redis命令在慢速日志中占用CPU ,并且Python-rq腌制的作业数据的大小并不大.
根据文档,Python-rq将作业作为哈希对象插入Redis,并让Redis使相关键(500秒似乎是默认值)到期以除去作业.如果您有一些严重的吞吐量,那么Redis中的许多项目都会等待过期.与未决职位相比,他们的人数会很高.
您可以通过查看INFO命令结果中要过期的项目数来检查此点.
Redis到期基于惰性机制(在访问密钥时应用)和基于密钥采样的活动机制,该机制在事件循环中运行(在伪背景模式下,每100毫秒).关键是当活动的到期机制正在运行时,不能处理Redis命令.
为避免过多地影响客户端应用程序的性能,每次触发活动机制时(默认情况下,10个键)仅处理有限数量的键.但是,如果发现超过25%的密钥已过期,它会尝试使更多密钥和循环失效.这是此概率算法自动调整其活动与Redis必须到期的密钥数量的方式.
当许多密钥要过期时,这种自适应算法会显着影响Redis的性能.您可以在此处找到更多信息.
我的建议是尝试通过设置expiration来阻止Python-rq将项目清理委托给Redis.无论如何,这对于排队系统来说是一种糟糕的设计.
| 归档时间： |
|
| 查看次数： |
2999 次 |
| 最近记录： |