Windows 上の WebLogic 11g で Java アプリケーションを実行していますが、数日後に応答しなくなります。私が気付いた疑わしい症状の 1 つは、サーバーがアイドル状態の場合でも、多数の接続 (約 3000)netstat
が CLOSE_WAIT ステータスで表示されることです。アプリケーション サーバーがクライアント接続を管理しているため、何が原因なのかわかりません。また、同じサーバーにループバックする Web サービス呼び出しも多数行っていますが、それらの接続は適切に閉じられると思います。他に何が原因で、このような問題をどのようにトラブルシューティングしますか?
6 に答える
私は同じ問題を抱えていて、この問題を取り除くためにソケットを研究しています。
いくつかの言葉を言わせてください。しかし、その前に、私は Java プログラマーではありません。
ブライアン・ホワイトが言うべきことはすべて言ったので、close_wait とは何かについては説明しません。
close_wait を回避するには、サーバーが応答を返した後に接続を閉じないようにする必要があります。そのため、サーバーが close_wait でスタックしている場合、応答を送信した後にサーバーが切断されていることがわかります。
いくつかのことを行うことで、それを回避する必要があります。
1 - クライアント アプリケーションが http 1.1 プロトコルを使用していない場合は、'keep-alive
http ヘッダー オプションにより、それを使用するように設定する必要があります。
2 - クライアントが http 1.1 を実行していて動作しない場合、または http 1.0 を使用する必要がある場合は、接続要求ヘッダー プロパティを設定する必要があります。
connection: keep-alive
これは、リクエストの完了後にクライアントもサーバーも切断しないことをサーバーに伝えます。そうすることで、サーバーはリクエストを受信するたびに切断されなくなります。
3 - クライアントで、ソケットを再利用します。たとえば、ループ内に多数のソケット クライアントを作成している場合は、ソケットを一度作成すると、要求を送信する必要があるたびにソケットが使用されます。私がアプリで使用したアプローチは、ソケット プールを用意し、1 つのソケットを使用可能にすることです (既にサーバーに接続されており、キープアライブ プロパティがあります)。それから私はそれを使用し、完了したらプールに戻して再利用できるようにします。
4 - リクエストの送信後に本当に切断する必要がある場合は、クライアントがそれを行っていることを確認し、connection: keep-alive
.
はい、サーバー側で多くの close_waits または time_waits がある場合、問題が発生する可能性があります。
この[リンク][1]をチェックして、何が何であるかを説明してkeep-alive
ください。
これがお役に立てば幸いです。それらのことで、私は自分の問題を解決することができました。
[1]: http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01.html#Persistent Connections
CLOSE_WAIT
リモート ホストが FIN を送信する (接続を閉じる) ときのローカル TCP ステート マシンの状態ですが、ローカル アプリケーションは同じことを行わず、応答 FIN を送信します。この時点で、ローカル マシンがデータを送信することはまだ可能ですが、クライアントはデータを受信できません (接続でハーフ クローズのみを行った場合を除きます)。
リモート ホストが閉じる (FIN を送信する) と、ローカル アプリケーションは何らかのイベント (ベース C ライブラリのソケットでの「読み取り」イベント) を受け取りますが、その接続から読み取るとエラーが返されて、接続が閉じました。この時点で、ローカル アプリケーションは接続を閉じる必要があります。
私は Java についてはほとんど知らず、WebLogic についても何も知りませんが、アプリケーションが読み取りエラーを適切に処理しておらず、接続を閉じていない可能性があると思います。
ステータスはCLOSE_WAIT
、反対側が接続のクローズを開始したが、ローカル側のアプリケーションがまだソケットをクローズしていないことを意味します。
ローカルアプリケーションにバグがあるようです。
この問題は、webLogic で「Use JSSE SSL」を true に設定することによって引き起こされるバグでした。JSSE の代わりに WebLogic 独自の SSL 実装を使用しても問題はありません。
CLOSE_WAIT パイルアップに関する次の引用を見つけました。これが起こり得る方法の。」
考えてみてください: リクエストの処理中にアプリケーションが動かなくなる可能性はありますか? それともWebLogic自体?
調査: Java スレッド ダンプ (Oracle JVM for Linux では kill -SIGQUIT を使用できます) を実行して、実際にスタックしているスレッドがあるかどうかを確認できますか?
クライアント側を調べます。まず、CLOSE_WAIT ソケットに接続されているクライアントの IP アドレスまたはホスト名を見つけます。次に、それらのクライアントで疑わしいことが起こっていないかどうかを確認します。