Redis が遅い理由とそのトラブルシューティング方法についての簡単な説明

この記事は、Redis に関する関連知識を提供するもので、主に Redis が遅い原因とそのトラブルシューティング方法を紹介し、サンプルコードを通じて詳しく紹介されており、誰にとっても非常に役立ちます。または、働くことには一定の参考学習価値があります。見てみましょう。皆さんのお役に立てれば幸いです。

推奨される学習: Redis ビデオ チュートリアル

原因 1: インスタンスのメモリが上限に達した

トラブルシューティングのアイデア

Redis インスタンスでメモリ制限 maxmemory が設定されている場合、Redis の速度が低下する可能性があります。

Redis を純粋なキャッシュとして使用する場合、通常、このインスタンスのメモリ上限 maxmemory を設定してから、データ削除戦略を設定します。インスタンスのメモリが maxmemory に達すると、その後新しいデータを書き込むたびに操作遅延が増加する場合があります。

速度低下の原因

Redis メモリが maxmemory に達すると、Redis は新しいデータを書き込む前に毎回インスタンスから一部のデータを追い出す必要があります。インスタンス全体のメモリを以下に維持してください。新しいデータを書き込む前に maxmemory を実行します。

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

• allkeys-lru: キーの有効期限に関係なくset、最も最近アクセスされたキーを削除します
• volatile-lru: 有効期限が設定された最も最近アクセスされたキーのみを削除します set
• allkeys-random: キーが期限切れに設定されているかどうかに関係なく、キーをランダムに削除する
• volatile-random: 有効期限が設定されているキーのみがランダムに削除されます
• allkeys-ttl: キーの有効期限が設定されているかどうかに関係なく、期限切れが近づいているキーは削除されます。削除される
• noeviction: キーは削除されません。インスタンスのメモリが maxmeory に達すると、新しいデータが書き込まれ、エラーが直接返されます。
• allkeys-lfu: キーが削除されるかどうかに関係なく、有効期限が設定されている場合、アクセス頻度が最も低いキーが削除されます (バージョン 4.0 でサポート)
• volatile-lfu: アクセス頻度が最も低いキーのみを削除し、有効期限キーを設定します (バージョン 4.0 でサポート)

どの戦略を使用するかは、特定のビジネス シナリオの構成によって異なります。最も一般的に使用される削除戦略は、allkeys-lru / volatile-lru です。その処理ロジックは、毎回インスタンスからキーのバッチをランダムに取り出し (この数は構成可能)、次に最もアクセスの少ないキーの 1 つを削除し、その後、残りのキーを使用します。キーをプールに一時的に保存し、引き続きキーのバッチをランダムに選択し、それらを前のプール内のキーと比較して、最もアクセスの少ないキーを削除します。インスタンスのメモリが maxmemory を下回るまで、これを繰り返します。

Redis 内のデータを削除するロジックは、期限切れのキーを削除するロジックと同じであり、コマンドが実際に実行される前に実行されるため、遅延も増加することに注意してください。また、書き込み OPS が高くなるほど遅延が顕著になります。

さらに、この時点で bigkey も Redis インスタンスに保存されている場合、bigkey を削除してメモリを解放するのにも時間がかかります。 ＃＃＃＃＃＃あなたはそれを見ましたか？ bigkey の危険はどこにでも存在します。これが、bigkey を保存しないようにするよう以前に注意した理由です。

解決策

ビッグキーの保存を回避し、メモリの解放時間を短縮します

• 消去戦略がランダム消去とランダム消去に変更されました。 LRU よりも優れています はるかに高速です (ビジネス状況によって異なります)
• インスタンスを分割し、キー削除の圧力を複数のインスタンスに分散します
• Redis 4.0 以降を使用している場合は、有効にしますlayz-free メカニズムでは、キーを削除してメモリを解放する操作をバックグラウンド スレッドに配置します (lazyfree-lazy-eviction = yes の設定)
• #原因 2: 大きなメモリ ページをオンにする

トラブルシューティングのアイデア

##アプリケーションがオペレーティング システムからメモリを申請する場合、メモリ ページ単位で適用され、従来のメモリ ページ サイズは 4KB であることは誰もが知っています。

2.6.38 以降、Linux カーネルはメモリ ヒュージ ページ メカニズムをサポートします。これにより、アプリケーションはオペレーティング システムから 2MB 単位でメモリを申請できるようになります。

• アプリケーションがオペレーティング システムに毎回適用するメモリ ユニットは大きくなりますが、これはメモリの適用にかかる時間も長くなるということを意味します。
• 速度低下の原因

• Redis がバックグラウンドで RDB と AOF の書き換えを実行している場合、fork 子プロセスを使用して処理します。ただし、メインプロセスが子プロセスをフォークした後も、この時点でメインプロセスは書き込みリクエストを受け取ることができ、受信した書き込みリクエストは Copy On Write (コピーオンライト) メソッドを使用してメモリデータを操作します。
• 言い換えると、メイン プロセスに変更が必要なデータがあると、Redis は既存のメモリ内のデータを直接変更するのではなく、まずメモリ データをコピーしてから、メモリ内のデータを変更します。新しいメモリ。これは「コピーオンライト」と呼ばれます。
• コピーオンライトは、書き込む必要がある人が最初にコピーしてから変更する必要があると理解することもできます。
• この利点は、親プロセスによる書き込み操作が子プロセスのデータの永続性に影響を与えないことです (子プロセスは、フォークの時点でインスタンス全体のすべてのデータを永続化するだけであり、子プロセスにはメモリ スナップショットのみが必要であり、その後ディスクに保存されるため、新しいデータの変更は気にしません)。
• ただし、メイン プロセスがメモリ データをコピーしているとき、この段階には新しいメモリの適用が含まれることに注意してください。この時点でオペレーティング システムが大きなメモリ ページを有効にしている場合は、この期間中、たとえクライアント 10B のデータのみが変更された場合、Redis はメモリを適用するときに 2MB 単位でオペレーティング システムにも適用します。メモリの適用にかかる時間が長くなり、各書き込みリクエストの遅延が増加し、Redis に影響を与えます。パフォーマンス。
• 同様に、この書き込みリクエストが bigkey 上で動作する場合、メイン プロセスが bigkey メモリ ブロックをコピーするときに、一度に要求されるメモリが大きくなり、時間が長くなります。ここでも bigkey がパフォーマンスに影響を与えていることがわかります。

解決策

ヒュージ ページ メカニズムをオフにします。

まず、Redis マシンでラージ メモリ ページが有効になっているかどうかを確認する必要があります。

$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

出力オプションが always の場合、ラージ メモリ ページ メカニズムが現在有効であることを意味します。

$ echo never > /sys/kernel/mm/transparent_hugepage/enabled

実際、オペレーティング システムが提供するラージ メモリ ページ メカニズムの利点は、特定のプログラムに対するアプリケーション メモリ リクエストの数を削減できることです。

ただし、パフォーマンスと遅延に非常に敏感な Redis のようなデータベースの場合、Redis がメモリに適用するたびにかかる時間ができるだけ短いことが望まれるため、このメカニズムを有効にすることはお勧めしません。 Redis マシン上で。

原因 3: スワップを使用する

トラブルシューティングのアイデア

Redis が突然非常に遅くなった場合は、各操作に最大で数百ミリ秒かかります。偶数秒の場合は、Redis が Swap を使用しているかどうかを確認する必要がありますが、この場合、Redis は基本的に高パフォーマンスのサービスを提供できません。

速度低下の原因

スワップとは何ですか?スワップを使用すると Redis のパフォーマンスが低下するのはなぜですか?

オペレーティング システムについてある程度の知識がある場合は、メモリ不足によるアプリケーションへの影響を軽減するために、オペレーティング システムではメモリ内のデータの一部をディスクに移動できることをご存知でしょう。アプリケーションのメモリ使用量をバッファリングします。これらのメモリ データは、ディスク上のスワップ領域にスワップされます。

問題は、メモリ内のデータがディスクに移動されると、Redis がそのデータに再度アクセスするときに、ディスクからデータを読み取る必要があることです。ディスクへのアクセス速度は、メモリ内のデータの数百倍遅いです。記憶にアクセス中！特に、非常に高いパフォーマンス要件があり、パフォーマンスに非常に敏感な Redis のようなデータベースの場合、この操作の遅延は許容できません。

この時点で、Redis マシンのメモリ使用量をチェックして、スワップが使用されているかどうかを確認する必要があります。 Redis プロセスが Swap を使用しているかどうかは、次の方法で確認できます。

# 先找到 Redis 的进程 ID
$ ps -aux | grep redis-server
 
# 查看 Redis Swap 使用情况
$ cat /proc/$pid/smaps | egrep '^(Swap|Size)'

出力結果は次のとおりです

サイズ: 1256 KB
スワップ: 0 KB
サイズ: 4 Kb
スワップ: 0 KB
サイズ: 132 KB
スワップ: 0 KB
サイズ: 63488 KB
スワップ: 0 KB
サイズ: 132 KB
スワップ: 0 KB
サイズ: 65404 KB
スワップ: 0 kb
サイズ: 1921024 kb
スワップ: 0 kB
....

この結果には、Redis プロセスのメモリ使用量がリストされます。

Size の各行は、Redis によって使用されるメモリのサイズを表します。Size の下の Swap は、メモリのサイズと、ディスクにスワップされたデータの量を表します。これら 2 つの値がある場合、が等しい場合は、ブロック メモリ内のデータがディスクに完全にスワップされたことを意味します。

少量のデータのみがディスクにスワップされる場合、たとえば、各スワップが対応するサイズの小さな割合を占める場合、影響は大きくありません。数百メガバイト、さらには GB のメモリがディスクにスワップされる場合は、Redis のパフォーマンスが確実に急激に低下するため、注意が必要です。

解決策

• Redis がメモリ空間を整理して十分な量を解放するために
• を使用するのに十分なメモリを確保できるように、マシンのメモリを増やします。メモリは Redis によって使用され、その後 Redis のスワップが解放され、Redis がメモリを再利用できるようになります。

Redis のスワップを解放するプロセスでは、通常、インスタンスを再起動する必要があります。インスタンスの再起動によるビジネスへの影響を考慮して、通常はマスター/スレーブのプロセスが最初に実行されます。切り替え、次に古いマスター ノードのスワップを解除し、古いマスター ノードのインスタンスを再起動し、スレーブ データベースのデータ同期が完了するまで待機します。その後、マスター/スレーブ切り替えを実行します。

Redis が Swap を使用すると、現時点での Redis の性能は基本的に高性能要件を満たせないことがわかります (格闘技が廃止されていることがわかります) ので、この事態を防ぐ必要もありますあらかじめ。

これを防ぐ方法は、Redis マシンのメモリとスワップの使用状況を監視し、メモリ不足またはスワップが使用されている場合にアラームを発し、タイムリーに対処する必要があります。

原因 4: ネットワーク帯域幅の過負荷

トラブルシューティングのアイデア

パフォーマンスの問題を引き起こす上記のシナリオを回避しており、Redis も安定している場合は、長い間稼働していたRedisの動作が、ある時期を境に急に遅くなり、それが続いているのですが、この状態は何が原因なのでしょうか？

このとき、Redis マシンのネットワーク帯域幅が過負荷になっていないか、マシン全体のネットワーク帯域幅を埋めているインスタンスが存在していないかを確認する必要があります。

速度低下の原因

ネットワーク帯域幅が過負荷になると、サーバーは TCP 層およびネットワーク層でパケット送信の遅延やパケット損失などが発生します。

Redis の高いパフォーマンスは、動作メモリに加えてネットワーク IO にもあり、ネットワーク IO にボトルネックがあると、Redis のパフォーマンスにも深刻な影響を及ぼします。

解決策

• Redis インスタンスがネットワーク帯域幅を使い果たしたことを時間内に確認します。通常のビジネス アクセスの場合は、拡張または移行する必要があります。このインスタンスのトラフィックが大きすぎるため、このマシンの他のインスタンスに影響を与えます。
• 運用保守レベルでは、ネットワークトラフィックを含むRedisマシンのさまざまな指標の監視を強化する必要があり、ネットワークトラフィックが一定のしきい値に達した場合、事前にアラームを発し、タイムリーに容量を確認および拡張する必要があります。やり方。

理由 5: その他の理由

1) 頻繁な短い接続

ビジネス アプリケーションは、頻繁な接続を避けるために、Redis を操作するために長い接続を使用する必要があります。短い接続。

短い接続が頻繁に発生すると、Redis は接続の確立と解放に多くの時間を費やし、TCP の 3 方向ハンドシェイクと 4 方向ウェーブもアクセス遅延を増加させます。

2) 運用とメンテナンスの監視

また、Redis の速度低下を事前に予測したい場合は、運用と保守の監視を適切に行うことが不可欠であることも前述しました。監視。 。

監視とは実際には Redis のさまざまなランタイムインジケーターの収集であり、監視プログラムが Redis の INFO 情報を定期的に収集し、INFO 情報内のステータスデータに基づいてデータの表示やアラームを実行するのが一般的です。

ここで注意していただきたいのは、監視スクリプトを作成したり、オープンソースの監視コンポーネントを使用したりするときは、軽視してはいけないということです。

Redis にアクセスする監視スクリプトを作成する場合は、頻繁に短い接続が行われないように、長い接続を使用してステータス情報を収集するようにしてください。同時に、ビジネス リクエストへの影響を避けるために、Redis へのアクセス頻度の制御にも注意を払う必要があります。

一部のオープンソース監視コンポーネントを使用する場合は、これらのコンポーネントの実装原則を理解し、これらのコンポーネントを正しく構成して、短期間に大量の Redis 操作が発生する監視コンポーネントのバグを防ぐことが最善です。時間がかかり、Redis のパフォーマンスに影響を与える可能性があります。

当時、DBA がいくつかのオープン ソース コンポーネントを使用していたときに、構成と使用法の問題により、監視プログラムが Redis から頻繁に確立および切断され、Redis の応答が遅くなるということが起こりました。

3) 他のプログラムがリソースをめぐって競合する

最後に、Redis マシンは最適な専用マシンであり、Redis インスタンスのデプロイにのみ使用されることを思い出してください。他のアプリケーションの場合は、他のプログラムが CPU、メモリ、およびディスク リソースを占有し、Redis に割り当てられるリソースが不十分になることを防ぐために、Redis に比較的「静かな」環境を提供するようにしてください。

推奨される学習: Redis ビデオ チュートリアル

以上がRedis が遅い理由とそのトラブルシューティング方法についての簡単な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。