Redis CPU 在排序集上的性能
我们正在运行 Redis，每秒对排序集中的键进行数百次增量，同时每秒对排序集进行数千次读取。
这似乎运行良好，但在峰值负载期间，CPU 使用率变得相当高，为单核的 80%。排序集本身占用的内存很小，只有几千个键。
CPU 使用率的增加是否可能是由于每秒数百次增量或数千次读取造成的？了解两者对性能的影响，但哪个影响更大？
鉴于此，在我的生产实例上监控以检查这些瓶颈的最佳指标是什么？
we are running redis and doing hundreds of increments per second of keys in a sorted set, and at the same time doing thousands of reads on the sorted set every second as well.
This seems to be working well but during peak load cpu usage gets pretty high, 80% of a single core. The sorted set itself is a small memory footprint of a few thousand keys.
is the cpu usage increase likely to be due to the hundreds of increments per second or the thousands of reads? understand both impact performance but which has the larger impact?
given this what are some of the best metrics to monitor on my production instance to review these bottlenecks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
需要检查的一点是排序集是否小到足以被 Redis 序列化。例如，“调试对象”可以应用于排序集的样本，以检查它们是否被编码为 ziplist。
ziplist 使用内存与 CPU 进行交换，特别是当排序集的大小接近阈值时（配置文件中的 zset-max-ziplist-entries、zset-max-ziplist-value）。
假设排序集不是 ziplist 编码的，我认为 CPU 使用率可能是由于每秒数千次读取而不是每秒数百次更新。 zset 的更新是一个 log(n) 操作。 Redis 速度非常快，并且不存在与锁定相关的延迟。 zset 项的读取是一个 O(n) 操作，可能会导致构建一个大缓冲区并将其返回给客户端。
可以肯定的是，您可能想要生成只读流量，检查 CPU，然后停止它，生成更新流量，再次检查 CPU 并进行比较。
zset 读取操作性能应接近您可以在 Redis 基准 中找到的 LRANGE 性能。具有数千个项目的 zset 的数千 TPS 似乎符合典型的 Redis 性能。
One point to check is whether the sorted sets are small enough to be serialized by Redis or not. For instance the "debug object" could be applied on a sample of sorted sets to check if they are encoded as ziplist or not.
ziplist usage trade memory against CPU, especially when the size of the sorted set is close to threshold (zset-max-ziplist-entries, zset-max-ziplist-value, in the configuration file).
Supposing the sorted sets are not ziplist encoded, I would say CPU usage is likely due to the thousands of reads per sec rather than the hundreds of updates per sec. An update of a zset is a log(n) operation. It is very fast, and there is no locking related latency with Redis. A read of the zset items is a O(n) operation, and may result in a large buffer to build and return to the client.
To be sure, you may want to generate the read only traffic, check the CPU, then stop it, generate the update traffic, check the CPU again and compare.
The zset read operations performance should be close to the LRANGE performance you can find in the Redis benchmark. A few thousands of TPS for zsets featuring a thousand of items seem to be in line with typical Redis performance.