この記事では、Redisに関する関連知識を中心に、Redisが遅くなる原因やトラブルシューティング方法などを中心に紹介していますので、一緒に見ていきましょう。 。 ヘルプ。
推奨される学習: Redis ビデオ チュートリアル
トラブルシューティングのアイデア
Redis インスタンスでメモリの上限を maxmemory に設定すると、Redis の速度が低下する可能性があります。
Redis を純粋なキャッシュとして使用する場合、通常、このインスタンスのメモリ上限 maxmemory を設定してから、データ削除戦略を設定します。インスタンスのメモリが maxmemory に達すると、その後新しいデータを書き込むたびに操作遅延が増加する場合があります。
速度低下の原因
Redis メモリが maxmemory に達すると、Redis は新しいデータを書き込む前に毎回インスタンスから一部のデータを追い出す必要があります。インスタンス全体のメモリを以下に維持してください。新しいデータを書き込む前に maxmemory を実行します。
古いデータを追い出すこのロジックにも時間がかかり、具体的な時間の長さは設定した削除戦略によって異なります:
どの戦略を使用するかは、特定のビジネス シナリオの構成によって異なります。最も一般的に使用される削除戦略は、allkeys-lru / volatile-lru です。その処理ロジックは、毎回インスタンスからキーのバッチをランダムに取り出し (この数は構成可能)、次に最もアクセスの少ないキーの 1 つを削除し、その後、残りのキーを使用します。キーをプールに一時的に保存し、引き続きキーのバッチをランダムに選択し、それらを前のプール内のキーと比較して、最もアクセスの少ないキーを削除します。インスタンスのメモリが maxmemory を下回るまで、これを繰り返します。
Redis 内のデータを削除するロジックは、期限切れのキーを削除するロジックと同じであり、コマンドが実際に実行される前に実行されるため、遅延も増加することに注意してください。また、書き込み OPS が高くなるほど遅延が顕著になります。
さらに、この時点で bigkey も Redis インスタンスに保存されている場合、bigkey を削除してメモリを解放するのにも時間がかかります。 ＃＃＃＃＃＃あなたはそれを見ましたか？ bigkey の危険はどこにでも存在します。これが、bigkey を保存しないようにするよう以前に注意した理由です。
解決策ビッグキーの保存を回避し、メモリの解放時間を短縮します
##アプリケーションがオペレーティング システムからメモリを申請する場合、メモリ ページ単位で適用され、従来のメモリ ページ サイズは 4KB であることは誰もが知っています。
2.6.38 以降、Linux カーネルはメモリ ヒュージ ページ メカニズムをサポートします。これにより、アプリケーションはオペレーティング システムから 2MB 単位でメモリを申請できるようになります。
解決策
ヒュージ ページ メカニズムをオフにします。
まず、Redis マシンでラージ メモリ ページが有効になっているかどうかを確認する必要があります。
$ cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never
出力オプションが always の場合、ラージ メモリ ページ メカニズムが現在有効であることを意味します。
$ echo never > /sys/kernel/mm/transparent_hugepage/enabled
実際、オペレーティング システムが提供するラージ メモリ ページ メカニズムの利点は、特定のプログラムに対するアプリケーション メモリ リクエストの数を削減できることです。
ただし、パフォーマンスと遅延に非常に敏感な Redis のようなデータベースの場合、Redis がメモリに適用するたびにかかる時間ができるだけ短いことが望まれるため、このメカニズムを有効にすることはお勧めしません。 Redis マシン上で。
トラブルシューティングのアイデア
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)'
出力結果は次のとおりです。
Size: 1256 kB Swap: 0 kB Size: 4 kB Swap: 0 kB Size: 132 kB Swap: 0 kB Size: 63488 kB Swap: 0 kB Size: 132 kB Swap: 0 kB Size: 65404 kB Swap: 0 kB Size: 1921024 kB Swap: 0 kB ...
この結果には、Redis プロセスのメモリ使用量がリストされます。
Size の各行は、Redis によって使用されるメモリのサイズを表します。Size の下の Swap は、メモリのサイズと、ディスクにスワップされたデータの量を表します。これら 2 つの値がある場合、が等しい場合は、ブロック メモリ内のデータがディスクに完全にスワップされたことを意味します。
たとえば、各スワップが対応するサイズの小さな割合を占めるなど、少量のデータのみがディスクにスワップされる場合、影響は大きくありません。数百メガバイト、さらには GB のメモリがディスクにスワップされる場合は、Redis のパフォーマンスが確実に急激に低下するため、注意が必要です。
解決策
Redis が Swap を使用する場合、この時点での Redis のパフォーマンスは基本的に高パフォーマンス要件を満たせないことがわかります (武道が廃止されることが理解できます) ので、この状況を事前に防ぐ必要もあります。
これを防ぐ方法は、Redis マシンのメモリとスワップの使用状況を監視し、メモリが不足している場合やスワップが使用されている場合にアラームを発し、適切なタイミングで対処する必要があることです。
トラブルシューティングのアイデア
パフォーマンスの問題を引き起こす上記のシナリオを回避しており、Redis も安定している場合は、長い間稼働していたRedisの動作が、ある時期を境に急に遅くなり、それが続いているのですが、この状態は何が原因なのでしょうか？
この時点で、Redis マシンのネットワーク帯域幅が過負荷になっているかどうか、およびマシン全体のネットワーク帯域幅を埋めているインスタンスが存在するかどうかを確認する必要があります。
速度低下の原因
ネットワーク帯域幅が過負荷になると、サーバーは TCP 層およびネットワーク層でパケット送信の遅延やパケット損失などが発生します。
Redis の高いパフォーマンスは、動作メモリに加えてネットワーク IO にもあり、ネットワーク IO にボトルネックがあると、Redis のパフォーマンスにも深刻な影響を及ぼします。
解決策
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 サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
