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のパフォーマンスに大きな影響を与える可能性があります。詳細については、こちらをご覧ください。
私の提案は、有効期限を設定することで、Python-rqがアイテムのクリーニングをRedisに委任しないようにすることです。とにかく、これはキューイングシステムには不十分な設計です。
Redis のキーが期限切れになったときに CPU の使用を避けるために、reduce ttl は適切な方法ではないと思います。
Didier 氏は、Python-rq の現在のアーキテクチャでは、キーの有効期限切れ機能を使用してクリーニング ジョブを Redis に委任していると、良い点を挙げて述べています。確かに、ディディエが言ったように、それは最善の方法ではありません。(これは、result_ttl が 0 より大きい場合にのみ使用されます)
次に、キー/ジョブのセットの有効期限が他のいずれかに近い場合に問題が発生し、ジョブの作成がバーストした場合に発生する可能性があります。
しかし、Python-rq は 1 つのワーカーでジョブが終了したときに期限切れキーを設定し、
この状況を回避するために、キーはその間に十分な時間を置いて分散する必要があるため、あまり意味がありません。