土曜日、本番サーバー上の Redis サーバーが利用できなくなり、エラー メッセージは次のようになりました。
下の図に示すように、6300 は Redis サーバーが実行されるポートです。 このような問題に遭遇したのは初めてでした。おそらく Redis がダウンしているのだろうと思い、telnet ip+port を使用しました。正常に動作していることがわかったので、redis を入力して現在の接続状態を確認することを考えました。ざっと見たところ、その数は1,903個にも上りました。 そこで、コードによって作成された redis 接続が多すぎることが原因だと思い、コードを確認しました。 redis は 1 か所のみに作成され、サービス登録時にも実行されることがわかります。つまり、アプリケーションの起動時に 1 回だけ実行されます。その後、プロジェクト全体が検索されましたが、redis の初期化と呼ばれる場所は他にありませんでした。 納得できません。Redis でデータを読み書きするたびに接続が作成されるということですか?頻繁に読んだり書いたりすることと関係があるのでしょうか?いつもうまくいかない気がするので、テストコードを作成してテストします。 ローカルに redis 環境を構築します。テストする前に、接続数を確認します。現在、接続数は 1 つだけであり、これが現在の cmd 接続クライアントです。これは正常です。 テストを開始し、プログラムを実行します。コードは接続オブジェクトを作成し、合計 1000 回の書き込みと 1000 回の読み取りをテストします。 接続をどのようにテストしても、常に 6 つの接続があります。つまり、プログラムは最大 5 つの接続 (主にスレッド プール) を作成します。 したがって、このコードの基本的な保存と読み取りには問題はまったくありません。 しかし、本番サーバーでは Docker 経由で約 6 つのアプリケーションが実行されていたため、コードのトラブルシューティングを完全にあきらめたわけではありません。それらはすべて同じ Redis に接続されています。他のアプリケーションが原因でしょうか? 次に、Redis 接続リスト内の任意のポートを介して対応するプロセス情報を直接照会し、それらがどのアプリケーションであるかを確認します。 Linux では、ネットワーク ポート番号を照会することでプロセス情報が表示されます。 netstat -atunlp | grep 60852 まず、このポートに対応する IP を確認します。たとえば、最初の IP は 172.17.0.1 です。 Docker に精通している学生であれば、この IP が Docker ゲートウェイ IP であることを知っておく必要があります。コンテナ内のプログラムはすべて、このゲートウェイ IP を介してホスト マシンと通信します。 ifconfig を通じて docker のゲートウェイ IP を見つけることができます。2 番目の 172.17.0.3:6379 は redis のコンテナ IP です。 この時点では、どのコンテナと接続を確立するかのプログラムが見つかりません。 最も愚かな方法は、コンテナに一つずつ入力することです。つまり、docker exec –it test /bin/bash を実行して、現在のコンテナのネットワーク接続ステータスを確認します。これは非常に面倒で、一連のコマンドを実行するために多くのコンポーネントをインストールする必要があります。 別の方法は、lsof コマンドを使用することです。このコマンドが利用できない場合はインストールする必要があります。このプロセスを通じてすべてのネットワーク接続を見つけることができます。 たとえば、メインプロセスは docker であり、その pid は 582251 であることがわかりました。 結果は下図の通りです。右側に実際に表示されるのは特定の IP です。この IP は Docker コンテナの特定の IP アドレスです。 すべての IP とポートがわかったので、コマンドの実行結果をダウンロードできます。 まず、各コンテナに対応する IP を見つけます。 docker examine name |grep IPAddress //name コンテナ名またはID 各 IP を見つけたら、ダウンロードしたすべてのネットワーク接続情報に基づいて統計を収集し、どの IP に最も多くの接続があるかを確認します。接続が最も多い IP には問題があるはずです。 次に、この IP に対応するコンテナにデプロイされたプログラムを見つけ、redis の設定を確認しました。スレッドプールが 200 に設定されていることがわかりました。 さらに、github を通じて、CSRedisCore にも preheat という予熱メカニズムがあり、そのデフォルト値は 5 つの予熱接続であることがわかりました。 スレッド プールは 200 に設定されており、さらに 5 つの接続用の予熱メカニズムがあります。200 * 5 = 1000 が作成されるかどうかはわかりません。時間があるときにソースコードを注意深く研究します。これは現時点では単なる推測です。 redis を poolsize=5、preheat=false に変更しました。スレッド プールには 5 つのスレッドがあり、予熱機構はオフになっています。 接続設定を変更し、アプリケーション サーバーと Redis サーバーを再起動した後 (確立された接続を完全にクリアするため)、接続数は減少しましたが、それほど大きな減少ではありませんでした。その後、Redis のアイドル時間が長すぎるため、接続プールが多くの接続を維持し、解放されないことが判明しました。 タイムアウトを30秒に設定しました CONFIG SET timeout 30 を実行します (単位は秒です。この方法は一時的な変更のみであり、現在の操作に有効です。長期的な効果を得るには、Redis 構成ファイルを変更することを忘れないでください) 次に接続数を確認します。接続数は一度に大幅に減少します。 要約: 1. Redis 接続が劇的に増加した場合、まずは自分のアプリケーションに問題があるかどうか調べます。たとえば、接続プールが大きすぎることと、デフォルトの予熱メカニズムに問題があることがわかりました。また、接続を作成するときにコード レベルが複数回トリガーされていないかどうかを確認してください。トリガーされている場合は、修正する必要があります。場所が複数回呼び出されるかどうかに応じて、インスタンスは注入によって作成されるようになりました。 2. 接続アイドル タイムアウトなどの Redis サーバー構成を変更します。最大接続数やデフォルト値も確認できます。 これで、Docker で Redis 接続が急増する問題のトラブルシューティングに関するこの記事は終了です。Docker で Redis 接続が急増する問題のトラブルシューティングに関する関連コンテンツの詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。 以下もご興味があるかもしれません:
|
<<: MySQL で union all を使用してユニオンソートを取得する方法
HTML は Hypertext Markup Language の略です。これは、実際のプレゼンテ...
目次01 YAMLファイルの概要YAML---キー値型YAML---リスト型02 K8Sにおけるマス...
目次1. シーン紹介2 コードの最適化2.1 ファンを増やす問題を解決する2.2 作品追加の問題を解...
MySQL バックアップコールドバックアップ:停止服務進行備份,即停止數據庫的寫入ホットバックアップ...
参考までに、Winでmysql5.7をインストールします。具体的な内容は次のとおりです。 @Auth...
1. Eコマースアイコン2. アイコンスイーツ2 3. 携帯電話アイコンパック4. 旗アイコンセット...
インターネットで見つけた方法は効果的ですinclude によって導入されたフッター ファイルとヘッダ...
1. まず、Linux サーバー上で公開鍵ファイルと秘密鍵ファイルを生成します。デフォルトの保存ディ...
数日前、バスで仕事に行きました。バスのカードリーダーの実際の使用シーンを実際に見て、カードリーダーの...
サーバーマッチングロジックNginx は、リクエストを実行するサーバー ブロックを決定するときに、サ...
目次ショートポーリングロングポーリングウェブソケットコミュニケーションの原則シンプルな1対1チャット...
目次導入例要約する導入$属性すべての親コンポーネントのプロパティを継承します (props を通じて...
1. iframe の定義と使用法iframe 要素は、別のドキュメントを含むインライン フレーム...
前回の記事では、Dockerの基礎知識であるローカルディレクトリのマウント方法を紹介しました。今日は...
目次スプリングブートDocker spring-boot-maven-プラグインSpotify Ma...