Redis で一般的なレイテンシの問題を解決する方法

非常に複雑なコマンドの使用

Redis の使用時にアクセス遅延が突然増加した場合、どのようにトラブルシューティングすればよいでしょうか?

まず、Redisの遅いログを確認することが第一ステップです。 Redis のスロー ログ コマンド統計機能を使用すると、次のオプションを設定して、どのコマンドが実行に大きな遅延を引き起こしているかを確認できます。

まず、Redis のスロー ログのしきい値を設定します。しきい値を超えたコマンドのみが記録されます。ここでの単位はマイクロ秒です。たとえば、スロー ログのしきい値を 5 ミリ秒に設定し、最新の 1,000 件のスローのみを設定します保持されるログ レコード。:

# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000

設定が完了すると、遅延が 5 ミリ秒を超える場合、実行されたすべてのコマンドが Redis によって記録されます。SLOWLOG get 5 を実行して、最後の 5 つのスロー ログをクエリします。

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 执行时间
   3) (integer) 5299        # 执行耗时(微妙)
   4) 1) "LRANGE"           # 具体执行的命令和参数
      2) "user_list_2000"
      3) "0"
      4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
      2) "book_price_1000"
...

遅いログを表示することによって、ログを通じて、どのコマンドをいつ実行するのに時間がかかるかを知ることができます。ビジネスで、sort、sunion、などの O(N) を超える複雑さのコマンドを頻繁に使用する場合、 zunionstore、keys、scan、または O(N) ) コマンドの実行時は比較的大量のデータを操作するため、これらの場合、Redis によるデータの処理に非常に時間がかかります。

Redis インスタンスの CPU 使用率が高いにもかかわらず、サービス リクエストの量が大きくない場合は、複雑なコマンドの使用が原因である可能性があります。

解決策は、これらの複雑なコマンドを使用せず、一度に大量のデータを取得せず、Redis が時間内に処理して返せるように、毎回少量のデータを操作するようにしてください。

Storage bigkey

遅いログをクエリして、複雑なコマンドが原因ではないことが判明した場合 (たとえば、遅いログ レコードに SET 操作や DELETE 操作が表示されるなど)、次のことを行う必要があります。 Redis が bigkey を書き込む状況はありますか?

Redis が新しいデータを書き込むと、そのデータにメモリ領域が割り当てられ、Redis からデータが削除されると、対応するメモリ領域も解放されます。

キーによって書き込まれるデータが非常に大きい場合、Redis のメモリ割り当てにも時間がかかります。同様に、このキーのデータを削除する場合も、メモリの解放に時間がかかります。

ビジネス コードをチェックして、bigkey が書き込まれているかどうかを確認する必要があります。書き込まれたデータの量を評価する必要があります。ビジネス レイヤーは、キーに過剰な量のデータを保存することを避ける必要があります。

bigkey の問題に対応して、Redis はバージョン 4.0 でレイジーフリー メカニズムを正式に開始しました。これは、bigkey のメモリを非同期的に解放し、Redis のパフォーマンスへの影響を軽減するために使用されます。それでも、bigkey の使用はお勧めしません。Bigkey は、クラスターの移行プロセス中の移行のパフォーマンスにも影響します。これについては、後ほどクラスター関連の記事で詳しく紹介します。

有効期限の集中管理

Redis を使用しているときに大きな遅延はないものの、ある時点で突然遅延の波が発生し、レポート時間が遅くなる場合があります。ポイントは、特定の時間や発生頻度など、非常に規則的です。

これが発生した場合は、まとめて期限切れになったキーが多数存在するかどうかを検討する必要があります。

一定の時点で多数のキーの有効期限が切れる場合、この時点で Redis にアクセスすると、遅延が増加する可能性があります。

Redis の有効期限戦略は、定期的な削除と遅延削除の 2 つの戦略を採用しています。

Redis の定期的な削除スケジュールされたタスクも、Redis メインスレッドで実行されることに注意してください。アクティブな有効期限が切れると、大量の期限切れのキーを削除する必要がある場合があり、その場合、ビジネス アクセス中に、有効期限タスクが完了した後でのみビジネス リクエストを処理する必要があります。このとき、業務アクセスの遅延が増大するという問題が発生し、最大遅延は25ミリ秒となります。

そして、このアクセス遅延は低速ログには記録されません。スローログには、特定のコマンドの実際の実行時間のみが記録されます。Redis アクティブ有効期限ポリシーは、運用コマンドの前に実行されます。運用コマンドの時間がスローログのしきい値に達していない場合、スローログの統計には計算されませんが、私たちのビジネスでは遅延が増加しています。

解決策は、一元化された有効期限にランダムな時間を追加し、有効期限が必要なこれらのキーの時間を分散することです。

インスタンスのメモリが上限に達しました

Redis を純粋なキャッシュとして使用する場合、インスタンスのメモリ上限 maxmemory を設定し、LRU 排除戦略を有効にすることがあります。

インスタンスのメモリが maxmemory に達すると、新しいデータの書き込みが毎回遅くなる可能性があることがわかります。

速度が低下する理由は、Redis メモリが maxmemory に達すると、新しいデータが書き込まれる前に、メモリを maxmemory 以下に保つためにデータの一部を追い出す必要があるためです。

古いデータを追い出すロジックにも時間がかかり、具体的な時間の長さは構成された削除戦略によって異なります

フォークには非常に時間がかかります

If Redis では RDB および AOF 書き換えを自動生成する機能が有効になっており、バックグラウンドで RDB および AOF 書き換えを生成する際に Redis のアクセス遅延が増加する場合がありますが、これらの作業が完了すると遅延は解消されます。

この種の状況は、通常、RDB と AOF の書き換えを生成するタスクの実行によって発生します。

RDB と AOF を生成するには、データの永続化のために親プロセスが子プロセスをフォークアウトする必要があります。フォーク実行プロセス中に、親プロセスはメモリ ページ テーブルを子プロセスにコピーする必要があります。インスタンス全体が大量のメモリを占有する場合、メモリの量が足りない場合は、コピーが必要です。メモリ ページ テーブルには時間がかかります。このプロセスは大量の CPU リソースを消費します。フォークが完了する前に、インスタンス全体がブロックされ、リクエストを処理できなくなります。現時点では CPU リソースが不足しているため、フォークにはさらに時間がかかり、第 2 レベルに到達する場合でも時間がかかります。これは Redis のパフォーマンスに重大な影響を与えます。

CPU のバインド

多くの場合、サービスをデプロイするときに、プログラムが複数の CPU を使用するときにパフォーマンスを向上させ、コンテキスト切り替えによるパフォーマンスの損失を軽減するために、通常、CPU へのプロセス バインドを使用します。 . 動作します。

ただし、Redis を使用する場合は、次の理由によりこれを行うことはお勧めしません。

バインドされた CPU Redis では、データの永続化を実行する際、フォークアウトされた子プロセスは親プロセスの CPU 使用率設定を継承し、このとき子プロセスはデータの永続化のために大量の CPU リソースを消費します。子プロセスがメインプロセスと CPU を競合するため、メインプロセスの CPU リソースが不足し、アクセス遅延が増加します。

したがって、Redis プロセスをデプロイするときに、RDB および AOF 書き換えメカニズムを有効にする必要がある場合は、CPU バインド操作を実行してはなりません

Swap を使用します

次のような場合は、 Redis が突然変化する 非常に遅く、アクセスごとに数百ミリ秒、場合によっては数秒かかる場合もありますので、Redis が Swap を使用しているかどうかを確認してください。この場合、Redis は基本的に高パフォーマンスのサービスを提供できません。

オペレーティング システムにはスワップ メカニズムが用意されていることがわかりました。その目的は、メモリが不足した場合にメモリ内のデータの一部をディスクにスワップして、メモリ使用量をバッファすることです。

しかし、メモリ内のデータがディスクにスワップされた後、データにアクセスするにはディスクから読み取る必要があり、メモリよりもはるかに時間がかかります。

特に Redis のような高パフォーマンスのインメモリ データベースの場合、Redis のメモリがディスクにスワップされる場合、この操作時間は Redis のようなパフォーマンスに非常に敏感なデータベースでは許容できないものになります。オペレーティング システムを一時的にシャットダウンできます。 Swap

ネットワーク カードの負荷が高すぎます

ある時点から速度が低下し始め、継続するのが特徴です。この時点で、マシンのネットワーク カードのトラフィックが枯渇しているかどうかを確認する必要があります。

ネットワーク負荷が高いと、ネットワーク層や TCP レベルでのデータ送信の遅延やデータ損失などの問題が発生する可能性があります。 Redis はメモリに加えて、優れたネットワーク IO パフォーマンスにより高性能です。ただし、リクエストの数が増加し続けると、それに応じてネットワーク カードの負荷も増加します。

これが発生した場合は、このマシン上のどの Redis インスタンスに過剰なトラフィックがあり、ネットワーク帯域幅をいっぱいにしているかを確認し、トラフィックの突然の増加が通常のビジネス状況であるかどうかを確認する必要があります。時間内に容量を拡張する必要があります。または、このマシンの他のインスタンスが影響を受けないようにインスタンスを移行してください。

以上がRedis で一般的なレイテンシの問題を解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。