人民醫(yī)院性能測(cè)試工作情況報(bào)告

1、人民醫(yī)院電子簽章及文檔服務(wù)器系統(tǒng) 性能測(cè)試工作情況報(bào)告 王宗成二零一三年六月 1 測(cè)試背景1.1測(cè)試目標(biāo)對(duì)北京人民醫(yī)院電子簽章服務(wù)器及文檔服務(wù)器系統(tǒng)進(jìn)行性能測(cè)試，客觀的評(píng)估系統(tǒng)的性能現(xiàn)狀。1、開發(fā)正確有效的性能測(cè)試腳本，模擬用戶現(xiàn)場(chǎng)操作行為，作為測(cè)試有效實(shí)施的基礎(chǔ)；2、通過性能測(cè)試，評(píng)估在公司內(nèi)部模擬環(huán)境下，被測(cè)系統(tǒng)的各項(xiàng)性能指標(biāo)表現(xiàn)；3、驗(yàn)證被測(cè)系統(tǒng)的系統(tǒng)業(yè)務(wù)處理能力和穩(wěn)定性，以及測(cè)試系統(tǒng)最高并發(fā)瓶頸是否能夠滿足在業(yè)務(wù)高峰期的性能要求，為被測(cè)系統(tǒng)上線提供參考依據(jù)。如不滿足，對(duì)性能瓶頸進(jìn)行定位分析，提供性能調(diào)優(yōu)建議。1.2測(cè)試人員王宗成2測(cè)試方法簡(jiǎn)介2.1壓力測(cè)試實(shí)施基本流程：l 測(cè)試環(huán)境準(zhǔn)備

2、使用人民醫(yī)院版本的文檔服務(wù)器和公章5.0及weblogic10.3.2，保證軟件版本一致。不過，人民醫(yī)院項(xiàng)目比較特殊，電子簽章服務(wù)器做了個(gè)性化開發(fā)，并非通用的公章5.0版本。用戶現(xiàn)場(chǎng)使用HPProliantDL380高性能機(jī)架式服務(wù)器和磁盤陣列。由于硬件條件的限制，本次性能測(cè)試的硬件平臺(tái)跟實(shí)際用戶環(huán)境有差距。l 測(cè)試腳本開發(fā)：該測(cè)試程序覆蓋典型用戶的系統(tǒng)訪問模式所涉及的操作。腳本的開發(fā)是利用LoadRunner Vugen進(jìn)行腳本錄制，開發(fā)，調(diào)試的過程。l 測(cè)試執(zhí)行：本次性能測(cè)試的關(guān)鍵點(diǎn)即查看人民醫(yī)院業(yè)務(wù)系統(tǒng)在并發(fā)壓力下的表現(xiàn)，即：支持的并發(fā)用戶數(shù)目以及在較大壓力下，系統(tǒng)的事務(wù)處理能力，并找出

3、各類事務(wù)的性能瓶頸。然后在指定的時(shí)間內(nèi)可對(duì)系統(tǒng)施實(shí)性能測(cè)試，性能測(cè)試執(zhí)行分為兩個(gè)階段：1、性能基準(zhǔn)測(cè)試：系統(tǒng)在輕負(fù)載環(huán)境下，評(píng)估當(dāng)前系統(tǒng)的性能表現(xiàn)，并作為后續(xù)壓力測(cè)試的性能比較基準(zhǔn)；2、負(fù)載壓力測(cè)試：模擬大批量并發(fā)業(yè)務(wù)，評(píng)估系統(tǒng)在高負(fù)載情況下系統(tǒng)的性能表現(xiàn)。l 測(cè)試結(jié)果分析報(bào)告：壓力測(cè)試結(jié)果經(jīng)過確認(rèn)有效后，將匯總壓力測(cè)試結(jié)果，形成性能測(cè)試分析報(bào)告。3測(cè)試環(huán)境3.1公司內(nèi)部模擬環(huán)境服務(wù)器地址配置說明硬件說明系統(tǒng)應(yīng)用服務(wù)器06操作系統(tǒng)：Red Hat Enterprise Linux Server 5.4（64位）中間件：Wenlogic10.3.2處理器：Intel Co

4、re i5 3.2 GHz，內(nèi)存：6GB數(shù)據(jù)庫服務(wù)器6Oracle 11g R2（64位）處理器：Intel Core2 2.5 GHz，內(nèi)存：4GB負(fù)載生成測(cè)試機(jī) Load Runner 9.50處理器：Intel Core i5 2.5 GHz，內(nèi)存：4GB備注：本次壓力測(cè)試的網(wǎng)絡(luò)環(huán)境為內(nèi)部局域網(wǎng)。院方服務(wù)器端設(shè)備型號(hào)：名稱類型種類數(shù)量服務(wù)器HP ProLiant DL380G6機(jī)架式5磁盤陣列HP STORAGEWORKS HSV300（容量：450G*12）機(jī)架式13.2測(cè)試工具本次性能測(cè)試采用逐步增加壓力的壓力測(cè)試模式來執(zhí)行，查看應(yīng)用系統(tǒng)在各種壓力狀

5、況下的性能表現(xiàn)。采用HP公司的LoadRunner創(chuàng)建虛擬用戶腳本工具Virtual User Generator、創(chuàng)建、運(yùn)行實(shí)際場(chǎng)景工具Controller、分析測(cè)試結(jié)果工具Analysis。采用QUEST公司的Spotlight on Oracle軟件來監(jiān)控Oracle數(shù)據(jù)庫，其優(yōu)點(diǎn)是實(shí)時(shí)準(zhǔn)確、界面直觀、操作配置簡(jiǎn)單靈活、性能消耗可以限定在一個(gè)小范圍內(nèi)、不需要在被監(jiān)控設(shè)備部署Agent代理。采用VisualVM 監(jiān)控在 Java 虛擬機(jī) (Java Virutal Machine, JVM) 上運(yùn)行的 Java 應(yīng)用程序的詳細(xì)信息。4測(cè)試設(shè)計(jì)4.1性能需求依據(jù)現(xiàn)場(chǎng)實(shí)施人員提供性能需求：目前

6、醫(yī)生站目前有400個(gè)左右。建議相關(guān)并發(fā)數(shù)最少為400。系統(tǒng)上線后業(yè)務(wù)量大概一天在13000左右。4.2模擬用戶數(shù)依據(jù)現(xiàn)場(chǎng)實(shí)施人員提供的業(yè)務(wù)量數(shù)據(jù)和對(duì)系統(tǒng)上線后業(yè)務(wù)量預(yù)估，對(duì)當(dāng)前系統(tǒng)分別按400用戶、100用戶進(jìn)行壓力測(cè)試，以評(píng)估系統(tǒng)在不同壓力梯度情況下的性能表現(xiàn)。4.3測(cè)試模型建立此次性能測(cè)試的業(yè)務(wù)選擇，應(yīng)覆蓋各性能關(guān)鍵業(yè)務(wù)，依實(shí)施人員提供數(shù)據(jù)設(shè)計(jì)本次性能測(cè)試共兩類場(chǎng)景，即長(zhǎng)時(shí)間低壓力并發(fā)和高負(fù)載并發(fā)兩類場(chǎng)景，前者采用100個(gè)用戶（Vuser）持續(xù)并發(fā)120分鐘來測(cè)試系統(tǒng)業(yè)務(wù)處理能力和穩(wěn)定性；后者采用400用戶并發(fā)5分鐘來測(cè)試系統(tǒng)最高并發(fā)瓶頸。除對(duì)兩類場(chǎng)景執(zhí)行的虛擬用戶和加壓時(shí)長(zhǎng)做調(diào)整外，其他

7、的環(huán)境和數(shù)據(jù)都一樣。 選定如下業(yè)務(wù)：² login代表登錄的事務(wù)，對(duì)應(yīng)的時(shí)間表示登錄事務(wù)所需的最小時(shí)間、平均時(shí)間和最大時(shí)間；² stamp代表簽章事務(wù)，對(duì)應(yīng)的時(shí)間表示簽章事務(wù)所需的最小時(shí)間、平均時(shí)間和最大時(shí)間；² upload 代表上傳事務(wù)，對(duì)應(yīng)的時(shí)間表示完成上傳事務(wù)所需的最小時(shí)間、平均時(shí)間和最大時(shí)間；² logout代表注銷的事務(wù)，對(duì)應(yīng)的時(shí)間表示注銷事務(wù)所需的最小時(shí)間、平均時(shí)間和最大時(shí)間；業(yè)務(wù)場(chǎng)景一1、 模擬用戶數(shù)：1002、 Pacing：130分鐘；3、 當(dāng)所有用戶加載完畢后連續(xù)運(yùn)行120分鐘；4、 用戶調(diào)度策略：每5秒啟動(dòng)1個(gè)虛擬用戶。業(yè)務(wù)場(chǎng)景二

8、1、 模擬用戶數(shù)：4002、 Pacing：45分鐘；3、 當(dāng)所有用戶加載完畢后連續(xù)運(yùn)行5分鐘；4、 用戶調(diào)度策略：每5秒啟動(dòng)1個(gè)虛擬用戶。5測(cè)試結(jié)果分析 5.1業(yè)務(wù)場(chǎng)景一測(cè)試結(jié)果5.1.1平均響應(yīng)時(shí)間測(cè)試使用了400個(gè)并發(fā)用戶，并發(fā)用戶的啟動(dòng)信息如下：各事務(wù)的響應(yīng)時(shí)間 （秒）ColorScale事務(wù)最小平均最大1登錄0.0080.0423.7151登出0.0040.0212.4091簽章0.050.2047.3891上傳0.0390.17616.522各事務(wù)的平均響應(yīng)時(shí)間圖：平均響應(yīng)時(shí)間分析：從上圖中可以看出，各操作的響應(yīng)時(shí)間隨著用戶數(shù)的增加呈平穩(wěn)趨勢(shì)，都沒有超過1秒，在可接受范圍內(nèi)。5.1

9、.2系統(tǒng)處理能力測(cè)試中，每秒的點(diǎn)擊率如下：測(cè)試中吞吐量如下：事務(wù)總體分析圖表：ColorScaleMeasurement1Fail1Pass系統(tǒng)處理能力分析：可以看出，系統(tǒng)處理能力隨用戶數(shù)的增加呈線性上升趨勢(shì)，即未出現(xiàn)性能瓶頸，100用戶時(shí)系統(tǒng)業(yè)務(wù)處理能力達(dá)到每小時(shí)3800筆。 24小時(shí)可處理91000筆。業(yè)務(wù)量分析依據(jù)用戶提供的數(shù)字，系統(tǒng)上線后訪問業(yè)務(wù)量期望在0:00-24:00這一時(shí)間段內(nèi)達(dá)到13000。根據(jù)這樣的業(yè)務(wù)量，采用二八原則進(jìn)行業(yè)務(wù)量與業(yè)務(wù)時(shí)間段的重新規(guī)劃，即為80%的業(yè)務(wù)量在20%的時(shí)間內(nèi)完成。那么1.3萬訪問量的80%即為1.04萬，而24個(gè)小時(shí)的20%即為4.8小時(shí)。故本次

10、測(cè)試，如果性能滿足4.8小時(shí)內(nèi)完成1.04萬的業(yè)務(wù)訪問量，即每小時(shí)2170的業(yè)務(wù)訪問量為測(cè)試通過。而本次測(cè)試100用戶時(shí)系統(tǒng)處理能力達(dá)到每小時(shí)3800筆，滿足并超出客戶提出的上線后每日完成1.3萬的處理能力。5.1.3資源利用率ColorScaleMeasurementMin.Ave.Max.100Average load (Unix Kernel Statistics):060.00.0740.46910CPU Utilization (Unix Kernel Statistics):060.01.29114.6490.1Paging rate

11、 (Unix Kernel Statistics):060.0232.969735.333資源利用率分析：在上圖中我們可以看出CPU、內(nèi)存利用率均在正常范圍內(nèi)，系統(tǒng)表現(xiàn)良好。5.2業(yè)務(wù)場(chǎng)景二測(cè)試結(jié)果5.2.1平均響應(yīng)時(shí)間測(cè)試使用了400個(gè)并發(fā)用戶，并發(fā)用戶的啟動(dòng)信息如下：各事務(wù)的響應(yīng)時(shí)間 （秒）ColorScale事務(wù)最小平均最大1登錄0.0047.603116.1651登出0.0050.76536.1291簽章0.04211.705149.4361上傳0.0313.671109.366各事務(wù)的平均響應(yīng)時(shí)間圖：平均響應(yīng)時(shí)間分析：可以看出隨著測(cè)試的進(jìn)行，事務(wù)相應(yīng)時(shí)間逐漸增

12、大，其中蓋章事務(wù)響應(yīng)時(shí)間最長(zhǎng)。12分鐘后最終導(dǎo)致超時(shí)而失敗。5.2.2系統(tǒng)處理能力測(cè)試中，每秒的點(diǎn)擊率如下：測(cè)試中吞吐量如下：系統(tǒng)處理能力分析：根據(jù)上面兩組數(shù)據(jù)，即：每秒的點(diǎn)擊率和吞吐量，可以看出，在測(cè)試執(zhí)行開始約10分鐘以后，用戶達(dá)到200以上，業(yè)務(wù)系統(tǒng)用戶登錄和簽章的并發(fā)數(shù)量不斷在增加，但是用戶登錄后的數(shù)據(jù)吞吐量卻變化不大，這樣將最終導(dǎo)致大量的用戶登錄因?yàn)槭聞?wù)處理超時(shí)而失敗。測(cè)試過程中高負(fù)載下Weblogic后臺(tái)發(fā)現(xiàn)有以下錯(cuò)誤：Ø 報(bào)錯(cuò)1：/usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)/

13、usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)/usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)/usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)/usr/StampServer5.0/StampServer/log/2013_6_5.log (Too many open files)Ø 報(bào)錯(cuò)2：<2013-5

14、-31 下午01時(shí)23分50秒 CST> <Error> <HTTP> <BEA-101104> <Servlet execution in servlet context "ServletContext17976572app:DocServer module:webroot path:/DocServer spec-version:2.5" failed, .ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes i

15、nstead of stated: '7420' bytes.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '7420' bytes.at ernal.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:425)at ernal.Ser

16、vletResponseImpl.ensureContentLength(ServletResponseImpl.java:1451)at ernal.ServletResponseImpl.send(ServletResponseImpl.java:1494)at ernal.ServletRequestImpl.run(ServletRequestImpl.java:1441)at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)Trunca

17、ted. see log file for complete stacktrace> <2013-5-31 下午01時(shí)23分50秒 CST> <Error> <HTTP> <BEA-101083> <Connection failure.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '2721' bytes.at ernal

18、.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:425)at ernal.ServletResponseImpl.ensureContentLength(ServletResponseImpl.java:1451)at ernal.ServletResponseImpl.send(ServletResponseImpl.java:1494)at ernal.ServletReq

19、uestImpl.run(ServletRequestImpl.java:1441)at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)Truncated. see log file for complete stacktrace> Ø 報(bào)錯(cuò)3：0x0a404c00 JavaThread "ACTIVE ExecuteThread: '100' for queue: 'weblogic.kernel.Default (self-tuning)'" daem

20、on _thread_blocked, id=23175, stack(0x31176000,0x311c7000) 0x0a403400 JavaThread "ACTIVE ExecuteThread: '99' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon _thread_blocked, id=23174, stack(0x311c7000,0x31218000) 0x0a401c00 JavaThread "ACTIVE ExecuteThread:

21、'98' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon _thread_blocked, id=23173, stack(0x31218000,0x31269000)5.2.3調(diào)優(yōu)設(shè)置1、 針對(duì)報(bào)錯(cuò)1，協(xié)調(diào)開發(fā)人員關(guān)閉后臺(tái)日志寫入和檢查寫文件后文件關(guān)閉情況。2、 針對(duì)報(bào)錯(cuò)2，協(xié)調(diào)開發(fā)人員，開發(fā)人員未能查明原因。3、 針對(duì)報(bào)錯(cuò)3，當(dāng)系統(tǒng)壓力超過測(cè)試最大壓力時(shí)，所有線程都被占用，引起線程阻塞。而JDBC連接使用服務(wù)器線程來執(zhí)行工作，沒有了線程就不能處理新的請(qǐng)求，嚴(yán)重會(huì)引起weblogi

22、c掛起現(xiàn)象。4、 增大WebLogic線程池大小，WebLogic10的線程池可以根據(jù)系統(tǒng)吞吐情況，自動(dòng)調(diào)整大小。設(shè)置調(diào)整臨界值為最小100，最大500。5、 增大Weblogic JVM內(nèi)存，Weblogic的啟動(dòng)內(nèi)存默認(rèn)配置為-Xms32m -Xmx256m，通過修改commEnv.sh提高JVM內(nèi)存。設(shè)置為最大1536M。6、 修改oracle的process為1000。 oracle數(shù)據(jù)庫和Weblogic的連接池的配置相關(guān)，所有Weblogic節(jié)點(diǎn)的連接池最大連接數(shù)之和不能大于oracle的最大線程數(shù)。 7、 將數(shù)據(jù)庫連接池最小連接數(shù)設(shè)置為20。連接池的最大連接數(shù)設(shè)為200。5.3場(chǎng)

23、景二調(diào)優(yōu)后測(cè)試結(jié)果5.3.1平均響應(yīng)時(shí)間第二次測(cè)試經(jīng)過了第一次的調(diào)優(yōu)，并且使用了Spotlight on Oracle來監(jiān)控Oracle數(shù)據(jù)庫，采用VisualVM 監(jiān)控JVM。運(yùn)行并發(fā)用戶400如下圖：各類事務(wù)的平均響應(yīng)時(shí)間如下表：（單位：秒）ColorScale事務(wù)最小平均最大1登錄0.0034.25186.5841登出0.0040.04621.1231簽章0.0242.5122.3111上傳0.0231.29830.789事務(wù)響應(yīng)時(shí)間時(shí)序圖如下：平均響應(yīng)時(shí)間分析：從圖中可以看出，隨著并發(fā)用戶數(shù)量的不斷增加，所有事務(wù)的平均響應(yīng)時(shí)間都在平穩(wěn)增加幅度較小，只有蓋章和登錄事務(wù)的耗時(shí)維持在較高水平

24、。5.3.2系統(tǒng)處理能力測(cè)試中每秒的點(diǎn)擊率如下：系統(tǒng)處理能力分析從圖中可以看出，系統(tǒng)處理能力隨著并發(fā)用戶數(shù)量的不斷增加，直到并發(fā)用戶數(shù)不再增加，這時(shí)候系統(tǒng)處理能力穩(wěn)定保持在峰值并出現(xiàn)一定波動(dòng)。5.3.3使用Spotlight實(shí)時(shí)監(jiān)控Oracle性能SESSION監(jiān)控從圖中可以看到，SID為409，用戶名為root的SESSION其當(dāng)前日志讀為每秒231.93個(gè)塊數(shù)，排名最前。圖中監(jiān)控性能消耗靠前的SQL語句截圖：整個(gè)場(chǎng)景運(yùn)行中出現(xiàn)的性能消耗靠前的其他SQL語句此SQL為文檔服務(wù)器為每一筆事務(wù)向數(shù)據(jù)庫loginfo表內(nèi)寫入交易日志，若無存在必要建議優(yōu)化，長(zhǎng)時(shí)間會(huì)引起數(shù)據(jù)庫表容量堆積過大。5.3.

25、4使用VisualVM監(jiān)控JVM：Weblogic JVM監(jiān)控分析：從圖中上部Heap圖可以看出，隨著并發(fā)用戶數(shù)量的不斷增加，used heap的折線圖呈鋸齒狀，說明垃圾對(duì)象及時(shí)被回收了，內(nèi)存得以釋放，沒有內(nèi)存泄漏。如果used heap的值只增不減說明存在內(nèi)存泄漏了，如果超過heap size的值，會(huì)報(bào)內(nèi)存溢出的錯(cuò)誤。圖中下部Thread圖可以看出，線程做出了自調(diào)整增大，隨著負(fù)載增大，最大線程自調(diào)優(yōu)至200，一般情況其上限是每個(gè)CPU對(duì)應(yīng)50個(gè)線程，其按照CPU個(gè)數(shù)線性增長(zhǎng)。6測(cè)試結(jié)論通過分析測(cè)試結(jié)果，可以得出以下結(jié)論，在公司內(nèi)部模擬環(huán)境下：1、測(cè)試系統(tǒng)的業(yè)務(wù)處理能力滿足每日業(yè)務(wù)量要求，長(zhǎng)時(shí)

26、間反復(fù)運(yùn)行中，系統(tǒng)未出現(xiàn)不良反應(yīng)，包括cpu、內(nèi)存占用過高、內(nèi)存泄漏等，系統(tǒng)響應(yīng)時(shí)間令人滿意，系統(tǒng)穩(wěn)定性比較可靠。能夠滿足系統(tǒng)上線后一天在13000左右業(yè)務(wù)量的要求。2、測(cè)試系統(tǒng)用戶并發(fā)量在300，能正常工作。當(dāng)并發(fā)用戶達(dá)到400時(shí)，部分用戶需要花10秒以上時(shí)間簽章和登錄，依據(jù)測(cè)試300到400用戶的情況下系統(tǒng)表現(xiàn)情況。結(jié)果發(fā)現(xiàn)系統(tǒng)在接近400時(shí)出現(xiàn)連接超時(shí)等現(xiàn)象，在本次測(cè)試環(huán)境下系統(tǒng)滿足并發(fā)300用戶。7存在問題及建議測(cè)試過程中高負(fù)載下Weblogic后臺(tái)發(fā)現(xiàn)有以下信息：Ø 報(bào)錯(cuò)1：<2013-6-3 下午02時(shí)44分15秒 CST> <Critical>

27、<Server> <BEA-002616> <Failed to listen on channel "Default" on 06:7001, failure count: 1, failing for 0 seconds, .SocketException: Too many open files> Ø 報(bào)錯(cuò)2：<2013-5-31 下午01時(shí)23分50秒 CST> <Error> <HTTP> <BEA-101104> <Servlet exec

28、ution in servlet context "ServletContext17976572app:DocServer module:webroot path:/DocServer spec-version:2.5" failed, .ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '7420' bytes.ProtocolException: Didn't meet stated Conte

29、nt-Length, wrote: '0' bytes instead of stated: '7420' bytes.at ernal.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:425)at ernal.ServletResponseImpl.ensureContentLength(ServletResponseImpl.java:1451)at weblogic.servlet

30、.internal.ServletResponseImpl.send(ServletResponseImpl.java:1494)at ernal.ServletRequestImpl.run(ServletRequestImpl.java:1441)at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)Truncated. see log file for complete stacktrace> <2013-5-31 下午01時(shí)23分50秒 CST> <Er

31、ror> <HTTP> <BEA-101083> <Connection failure.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '2721' bytes.at ernal.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:425)at weblo

32、ernal.ServletResponseImpl.ensureContentLength(ServletResponseImpl.java:1451)at ernal.ServletResponseImpl.send(ServletResponseImpl.java:1494)at ernal.ServletRequestImpl.run(ServletRequestImpl.java:1441)at weblogic.work.ExecuteThread.execute(Execu

33、teThread.java:201)Truncated. see log file for complete stacktrace> 1、針對(duì)滿負(fù)載運(yùn)行下login事務(wù)耗時(shí)大量增加的情況，請(qǐng)依據(jù)此weblogic后臺(tái)報(bào)錯(cuò)信息排查：<2013-6-3 下午02時(shí)44分15秒 CST> <Critical> <Server> <BEA-002616> <Failed to listen on channel "Default" on 06:7001, failure count: 1, failing for 0 seconds, .SocketException: Too many open files> 2、對(duì)于<BEA-101083>，此后臺(tái)報(bào)錯(cuò)協(xié)調(diào)開發(fā)人員未能查清