ソート済みセットの中で1秒間に数百回の増分を実行すると同時に、毎秒ソート済みセットに対して何千もの読み込みを実行しています。ソート済みセットのRedis CPUパフォーマンス
これはうまくいくようですが、ピーク負荷時にCPU使用率が単コアの80％と非常に高くなります。ソートされたセット自体は、数千個のキーの小さなメモリフットプリントです。
は、1秒あたり数百回の増分または数千回の読み取りによるものです。両方の衝撃性能を理解するが、それはより大きな影響を有するか？
これらのボトルネックを確認するために、本番インスタンスで監視するための最良のメトリックは何ですか？
ソートされたセットがRedisによってシリアル化されるのに十分小さいかどうかがチェックされます。例えば、ソートされたセットのサンプルに「デバッグオブジェクト」を適用して、ziplistとしてエンコードされているかどうかを確認することができます。
ziplist使用メモリとCPUとの比較、特にソートされたセットのサイズがしきい値に近い場合（構成ファイル内のzset-max-ziplist-entries、zset-max-ziplist-value）
並べ替えられたセットがziplistでエンコードされていないと仮定すると、CPU使用率は秒当たり何百もの更新ではなく、1秒あたり何千もの読み込みが原因と考えられます。 zsetの更新はlog（n）操作です。これは非常に高速で、Redisとのロック関連の遅延はありません。 zset項目の読み込みはO（n）操作であり、クライアントをビルドしてクライアントに返すために大きなバッファが発生する可能性があります。
読み取り専用トラフィックを生成し、CPUをチェックしてから停止し、更新トラフィックを生成し、再度CPUをチェックして比較したい場合があります。
zset読み取り操作のパフォーマンスは、Redis にあるLRANGEのパフォーマンスに近い値にする必要があります。何千もの項目を特色とする数千のTPS for zsetsは、典型的なRedisのパフォーマンスに沿っているようです。