我们正在运行redis并在一个有序集合中每秒执行数百个增量的键，同时每秒对有序集合执行数千次读取。
这似乎运行良好，但在峰值负载期间cpu使用率相当高，单核的80％。排序集本身就是几千个密钥的小内存占用。
cpu使用量的增加可能是由于每秒数百个增量或数千次读取？了解影响绩效但影响较大的影响？
考虑到这一点，我的生产实例上要监控哪些最佳指标来检查这些瓶颈？
答案 0 :(得分：2)
要检查的一点是，排序集是否足够小以便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 benchmark中可以找到的LRANGE性能。成千上万的TPS for zsets具有数千个项目，似乎与典型的Redis性能一致。