JBoss配置解決高並發串連異常問題(轉)

標籤：

 

這兩天一個項目在做壓力測試的時候，發現只要並發數超過250個，連續測試兩輪就會有串連異常出現，測試輪數越多出現越頻繁，異常日誌如下：

 

[plain] view plain copy  

1. Caused by: com.caucho.hessian.client.HessianConnectionException: 500: java.io.IOException: Error writing to server  
2.     at com.caucho.hessian.client.HessianURLConnection.sendRequest(HessianURLConnection.java:142)  
3.     at com.caucho.hessian.client.HessianProxy.sendRequest(HessianProxy.java:283)  
4.     at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:170)  
5.     at $Proxy168.sendOpenAcctInfo(Unknown Source)  
6.     at sun.reflect.GeneratedMethodAccessor750.invoke(Unknown Source)  
7.     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  
8.     at java.lang.reflect.Method.invoke(Method.java:597)  
9.     at org.springframework.remoting.caucho.HessianClientInterceptor.invoke(HessianClientInterceptor.java:219)  
10.     at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)  
11.     at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)  
12.     at $Proxy169.sendOpenAcctInfo(Unknown Source)  
13.     at com.shine.web.bean.OpenAcctBeanImpl.sendOpenAcctInfo(OpenAcctBeanImpl.java:62)  
14.     ... 32 more  
15. Caused by: java.io.IOException: Error writing to server  
16.     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)  
17.     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)  
18.     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)  
19.     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)  
20.     at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1345)  
21.     at java.security.AccessController.doPrivileged(Native Method)  
22.     at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1339)  
23.     at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:993)  
24.     at com.caucho.hessian.client.HessianURLConnection.sendRequest(HessianURLConnection.java:122)  
25.     ... 43 more  
26. Caused by: java.io.IOException: Error writing to server  
27.     at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:453)  
28.     at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:465)  
29.     at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1047)  
30.     at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373)  
31.     at com.caucho.hessian.client.HessianURLConnection.sendRequest(HessianURLConnection.java:109)  
32.     ... 43 more  

一開始使用Error writing to server去網路上尋找原因，發現基本都無關。

 

後來搜尋hessian和spring相容問題，發現spring2.5.6和hessian4.0.7不相容。將hessian版本號碼降低到3.1.3，情況有好轉，但測試10輪之後，異常又出現了。

通過記憶體監控，先排除虛擬機器記憶體問題。虛擬機器記憶體配置為-Xms1024m -Xmx1024m，監控下來發現實際佔用記憶體不到一半。

然後通過netstat -na監控作業系統連接埠佔用情況，發現連接埠佔用高峰不到500個，這個原因也排除了。（測試伺服器已經修改註冊表將TIME_WAIT時間降低到30秒，所以基本不會出現連接埠佔用問題）。

通過CPU監控，確認並發高峰時，CPU佔用也不到50%。

種種跡象表明，這些都不是造成串連斷開的原因，那到底瓶頸出現在哪裡呢？

於是我們將目光轉向JBoss的配置。

首先確認資料庫的串連池配置，最大串連數設定為50，從前幾輪都可以正常運行來看，資料庫連接應該夠用；

然後確認JBoss的線程池配置，發現預設配置如下：

 

[html] view plain copy  

1. <mbean code="org.jboss.util.threadpool.BasicThreadPool"  
2.    name="jboss.system:service=ThreadPool">  
3.    <attribute name="Name">JBoss System Threads</attribute>  
4.    <attribute name="ThreadGroupName">System Threads</attribute>  
5.    <!-- How long a thread will live without any tasks in MS -->  
6.    <attribute name="KeepAliveTime">60000</attribute>  
7.    <!-- The max number of threads in the pool -->  
8.    <attribute name="MaximumPoolSize">10</attribute>  
9.    <!-- The max number of tasks before the queue is full -->  
10.    <attribute name="MaximumQueueSize">1000</attribute>  
11.    <!-- The behavior of the pool when a task is added and the queue is full.  
12.    abort - a RuntimeException is thrown  
13.    run - the calling thread executes the task  
14.    wait - the calling thread blocks until the queue has room  
15.    discard - the task is silently discarded without being run  
16.    discardOldest - check to see if a task is about to complete and enque  
17.       the new task if possible, else run the task in the calling thread  
18.    -->  
19.    <attribute name="BlockingMode">run</attribute>  
20. </mbean>  

搜尋了一下相關配置的說明，在進行高並發的時候，建議修改MaximumPoolSize的大小為並發數的125%。

 

由於我們測試的不是持續的並發，因此將線程池大小修改成200先測試了一下，發現並發數在300的時候可以正常運行，又將並發數修改到500，持續測試了6個小時，均沒有發現異常。

現在比較好奇的是，為什麼250個並發的時候就能一直不出錯，超過250個並發，就會頻繁出錯，這個值和MaximumPoolSize的參數到底有什麼聯絡呢？

http://blog.csdn.net/nicholas_lin/article/details/20639481

 http://wenku.baidu.com/link?url=eUQiTt73bQN_XBHVNpAhDnSMYfLdfqQXK1AF5Pp2dhTgBrO4nHaws7rEm8WZY5WVIiOEUaX5UQuuQTNCM9DrsNMjetboto1NnikLSEtzH6S

JBoss配置解決高並發串連異常問題(轉)