JBoss構成高同時接続異常問題の解決
4680 ワード
この2日間、ある項目が圧力テストをしている時、合併数が250個を超えると、連続テストの2輪に接続異常が発生し、テスト輪数が多ければ多いほど頻繁に発生し、異常ログは以下の通りであることを発見した.
最初はError writing to serverを使ってネット上で原因を探していたが、基本的には関係ないことが分かった.
その後hessianとspringの互換性の問題を検索し、spring 2を発見した.5.6とhessian 4.0.7互換性がありません.hessianバージョン番号を3.1.3に下げ、状況は好転したが、テスト10ラウンド後、異常が再発した.
メモリモニタリングにより、仮想マシンのメモリの問題を排除します.仮想マシンのメモリは-Xms 1024 m-Xmx 1024 mに構成されており、監視すると実際のメモリ消費量は半分未満であることがわかります.
次にnetstat-naによりオペレーティングシステムのポート占有状況を監視したところ,ポート占有ピークは500個未満であることが分かったが,この原因も排除された.(テストサーバはレジストリを変更してTIME_WAIT時間を30秒に短縮しているので、ポート占有の問題はほとんど発生しません).
CPUモニタにより、同時ピーク時のCPU占有率も50%未満であることを確認します.
様々な兆候は、これらが接続の切断の原因ではないことを示していますが、ボトルネックはどこにあるのでしょうか.
そこでJBossの構成に目を向けました.
まず、データベースの接続プールの構成を確認し、最大接続数を50に設定し、前のラウンドから正常に動作していることから、データベース接続は十分であるはずです.
JBossのスレッドプール構成を確認すると、デフォルトの構成は次のとおりです.
関連する構成の説明を検索すると、高同時実行を行う場合は、MaximumPoolSizeのサイズを同時実行数の125%に変更することをお勧めします.
継続的な同時実行ではないため、スレッドプールのサイズを200に変更してテストしたところ、同時実行数は300で正常に動作し、同時実行数は500に変更され、6時間継続的にテストされたが、異常は認められなかった.
今では、なぜ250個の同時実行時にずっとエラーが発生しないのか、250個を超える同時実行で頻繁にエラーが発生するのか、この値とMaximumPoolSizeのパラメータにはいったい何の関係があるのだろうか.
Caused by: com.caucho.hessian.client.HessianConnectionException: 500: java.io.IOException: Error writing to server
at com.caucho.hessian.client.HessianURLConnection.sendRequest(HessianURLConnection.java:142)
at com.caucho.hessian.client.HessianProxy.sendRequest(HessianProxy.java:283)
at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:170)
at $Proxy168.sendOpenAcctInfo(Unknown Source)
at sun.reflect.GeneratedMethodAccessor750.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.remoting.caucho.HessianClientInterceptor.invoke(HessianClientInterceptor.java:219)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy169.sendOpenAcctInfo(Unknown Source)
at com.shine.web.bean.OpenAcctBeanImpl.sendOpenAcctInfo(OpenAcctBeanImpl.java:62)
... 32 more
Caused by: java.io.IOException: Error writing to server
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1345)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1339)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:993)
at com.caucho.hessian.client.HessianURLConnection.sendRequest(HessianURLConnection.java:122)
... 43 more
Caused by: java.io.IOException: Error writing to server
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:453)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:465)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1047)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at com.caucho.hessian.client.HessianURLConnection.sendRequest(HessianURLConnection.java:109)
... 43 more
最初はError writing to serverを使ってネット上で原因を探していたが、基本的には関係ないことが分かった.
その後hessianとspringの互換性の問題を検索し、spring 2を発見した.5.6とhessian 4.0.7互換性がありません.hessianバージョン番号を3.1.3に下げ、状況は好転したが、テスト10ラウンド後、異常が再発した.
メモリモニタリングにより、仮想マシンのメモリの問題を排除します.仮想マシンのメモリは-Xms 1024 m-Xmx 1024 mに構成されており、監視すると実際のメモリ消費量は半分未満であることがわかります.
次にnetstat-naによりオペレーティングシステムのポート占有状況を監視したところ,ポート占有ピークは500個未満であることが分かったが,この原因も排除された.(テストサーバはレジストリを変更してTIME_WAIT時間を30秒に短縮しているので、ポート占有の問題はほとんど発生しません).
CPUモニタにより、同時ピーク時のCPU占有率も50%未満であることを確認します.
様々な兆候は、これらが接続の切断の原因ではないことを示していますが、ボトルネックはどこにあるのでしょうか.
そこでJBossの構成に目を向けました.
まず、データベースの接続プールの構成を確認し、最大接続数を50に設定し、前のラウンドから正常に動作していることから、データベース接続は十分であるはずです.
JBossのスレッドプール構成を確認すると、デフォルトの構成は次のとおりです.
JBoss System Threads
System Threads
60000
10
1000
run
関連する構成の説明を検索すると、高同時実行を行う場合は、MaximumPoolSizeのサイズを同時実行数の125%に変更することをお勧めします.
継続的な同時実行ではないため、スレッドプールのサイズを200に変更してテストしたところ、同時実行数は300で正常に動作し、同時実行数は500に変更され、6時間継続的にテストされたが、異常は認められなかった.
今では、なぜ250個の同時実行時にずっとエラーが発生しないのか、250個を超える同時実行で頻繁にエラーが発生するのか、この値とMaximumPoolSizeのパラメータにはいったい何の関係があるのだろうか.