1. 事業背景
同社のビジネス シナリオでは、主にクラスター ノード間のセッション共有に Redis を使用しています。
2. エラーの理由
アイドル オブジェクトのタイムアウト待機は、Redis 接続プールにアイドル接続がないことを意味します。アイドル接続がない場合は、プール内の接続がリークしているか、接続が常にアクティブな状態によって占有されている (つまり、Redis がブロックされ、すべてのコマンドがブロックされ、アクティブな接続が維持される) ことを意味します。コードは長期間オンラインであり、最近変更されていないため、接続リークは無視できます。その後、Redis ブロックの問題を直接トラブルシューティングし
ます
。
3. 調査プロセス
1. 問題発生時点の確認
歴史的な理由を調査しているため、何らかの情報を取得するには、slowlog、redis.log、および info コマンドをクエリすることしかできません。そのため、問題が発生した時刻を確認することが非常に必要です。上のスクリーンショットから、エラー時刻は 17:38:38 です。
2. redis.log をクエリする
主に、 redis.log ログの 一部のログ エラー、RDB 情報出力、クラスター情報などをクエリします。
3. redis.conf をクエリする
この時点で、redis.conf で見つかった maxmemory が 6G であることを確認します。これは、短期間でデータの 1/3 を変更することに相当します。スクリーンショットはここでは提供されていません。
4. クエリ情報情報
rbd の最後のフォークには時間がかかり、かかる時間は最大 10 ミリ秒と大きくなく、この側面の影響は無視できることを確認します。スクリーンショットはここには提供されていません。
5. スローログのクエリ
クエリ履歴の遅いクエリでは、以下の zrem コマンドが同時に実行され、処理されるデータ量が多く、オブジェクトの削除操作が個別に
実行されます。
調査時点が 18:00 以降であるため、顧客環境のほとんどの人がすでに退社しているため、ビジネス要求は高くなく、訪問者もほとんどいません。この状態では、arem の削除されたオブジェクトはすべて見つかり、履歴の同時削除も存在します。そのため、zrem はビジネスの一致時に問題を引き起こす可能性が非常に高いです。レンシーは高い
。
6. 現在時刻の監視コマンドを問い合わせる
基本的にビジネスの同時実行性はなく、実際の基準値もありません。
4. 結論と解決策
主な結論の起源:
解決策:
関連するビジネス開発に、問題の原因、たとえば、大きなオブジェクトの rem 削除が同時に行われる場合の処理ニーズを通知します。 1.
zrem の使用を避ける
2. 頻度を減らす
3. zrem オブジェクトのサイズを減らし、同時に頻度を減らす。
処理の結果：
これはセッションに関連しているため、顧客環境は午後に作業終了まで苦労するまで午後に数回発生しました。問題が時間にチェックされない場合、次の日が発生する2番目の問題が非常に高いです。その時点では、次の一時的なソリューションが提供されました。翌日からは発生してい
ませ
ん
。