最近做的項目系統即將上線，一直在搞性能壓力測試。由於WAS7 也是第一次在項目上使用，發現了不少問題，也積累了一些經驗。下面就發現的一些問題做一些總結。
首先環境描述：
操作系統： RHEL 5.5
應用服務器： WAS 7ND + IHS7
數據庫：Orcale 11g RAC
應用服務器 3台機器，一台運行IHS，併當文件服務器運行。 另外2台 WAS7 集群，每台機器3個Server 。2台數據庫服務器集群。
先說一下壓力測試的幾個測試重點和其中發現的問題：
1、用戶並發登錄測試
用戶並發登錄測試，項目要求達到的最低要求是200的並發登錄。 我們自己的預想的要求是每個單節點最少並發50，集群環境並發300左右。並能夠持續承受壓力8小時。
這個地方的壓力測試出了非常低級、搞笑的錯誤，導致壓力測試結果非常不理想。現象就是單節點壓力測試，50並發，基本上半個小時後就內存溢出，然後宕機。 LoudRunner 顯示的成功完成事務數量是12000次左右。 這個問題查了很久，也找了IBM的服務，花了1個多星期的時間，最後分析了內存溢出的dump文件，才發現導致內存溢出的是因為session對象太多，佔用了系統大量內存。
後來問測試人員，壓力測試的腳本是怎麼錄的，才發現原來壓力測試的時候，只錄入了登錄，沒有錄入退出。這種測試腳本一運行，就會不斷的在WAS服務器上產生session以及應用系統中緩存在session中的對象，不點退出session 釋放不了，內存無法回收，結果導致怎麼壓都是死。修改測試腳本，加上退出的動作之後，重新測試，結果就比較理想了，沒再出過內存溢出的問題。
嗚呼哀哉。。。 希望壓力測試的時候，測試人員以後別犯這種低級錯誤了。真是浪費人力。不過話說回來，我們的平台框架在設計的時候應該也是有點問題的。因為在session中存入了大量的對象，這肯定會限制單個節點的最大用戶在線數量。就目前的壓力測試情況來看，如果系統有12000個用戶在線的話，系統就死翹翹了。
這個就是屬於登錄平台的問題，不是簡單可以解決的。
2、工作流業務提交並發測試
工作流的測試也分為2塊，單節點的流程提交和集群環境下的流程數據提交。單點測試50並發，基本上通過測試。
但是集群環境下就出現了問題。壓力測試到一定時間之後，在後台就會出現線程掛起的異常。從而導致WAS的某個節點宕機，最終也會導致IHS也死掉。
下面是出錯日誌摘要：
IHS error.log ：
[Thu Oct 20 10:58:24 2011] [notice] mpmstats: reached MaxClients (4000/4000)
[Thu Oct 20 10:58:24 2011] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
[Thu Oct 20 10:59:54 2011] [notice] mpmstats: reached MaxClients (4000/4000)
[Thu Oct 20 10:59:54 2011] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
[Thu Oct 20 11:01:24 2011] [notice] mpmstats: reached MaxClients (4000/4000)
[Thu Oct 20 11:01:24 2011] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
[Thu Oct 20 11:02:54 2011] [notice] mpmstats: reached MaxClients (4000/4000)
[Thu Oct 20 11:02:54 2011] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
其中最明顯的錯誤就是： mpmstats: reached MaxClients 這段了。 表示IHS的已經達到最大連接數，無法接受新的請求。 而且即使停掉壓力測試，連接也無法釋放。最後只能重啟IHS。
對應WAS後台，一般只有一個節點出現線程掛起的異常。SystemOut.log 日誌如下：
[11-10-21 3:28:12:760 CST] 000001f1 ThreadMonitor W WSVR0605W: 線程”WebContainer : 662″（000002f4）已保持活動狀態 621688 毫秒，此線程可能已掛起。在服務器中共有 177 個線程可能處於掛起狀態。
at java.util.Collections$SynchronizedSet.hashCode(Collections.java:835)
at com.ibm.ejs.j2c.PoolManager$SubjectHashCode.run(PoolManager.java:4948)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
at com.ibm.ejs.j2c.PoolManager.computeHashCode(PoolManager.java:4623)
at com.ibm.ejs.j2c.PoolManager.reserve(PoolManager.java:2190)
at com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java:1063)
at com.ibm.ejs.j2c.ConnectionManager.allocateConnection(ConnectionManager.java:700)
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:668)
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:635)
從日誌看，線程掛起在獲取數據源連接的地方。問題可能是由於集群環境下獲取數據源出現死鎖，從而導致資源無法釋放，最終線程池被耗盡，線程掛起。 最後只能重啟WAS服務。
這個問題的解決辦法是：在數據源裏面增加一個參數 useRRASetEquals 設置為 true
添加路徑：
資源 -> JDBC -> XXX數據源->定製屬性 -> 新建
增加參數： useRRASetEquals ，值為 true , 類型為 java.lang.Boolean
加上這個參數之後，再做測試，則上述問題解決。 集群環境下能夠支撐200並發提交工作流請求，持續運行2天。
這個參數應該是WAS7新加的，因為加這個參數有版本要求，必須是 7.0.0.13 之後的版本，否則會報錯。
3、附件上傳數據流量測試
這個模塊目前正在測試，如有問題再說。
WAS7集群上傳下載問題分析及動靜分離
繼續去年沒寫完的文檔，由於時間比較忙一直沒來得及總結。雖然系統已經上線運行快4個月了。中間出了一些大大小小的問題，下面就一一說明。
上次是寫到第3點：附件上傳數據流量測試
文件上傳的測試，通過測試工具進行測試基本上沒發現太大的問題，不過由於測試環境的網絡比較好，所以也很難發現問題。正式上線之後文件的上傳這塊也沒太大的問題，因為有問題也最多是上傳不了數據。J
但是對於附件的下載這塊卻沒有進行比較好的測試，導致上線的2個星期都出現了一個大問題。
問題主要出現在網站這塊， 由於網站上有提供不少幫助文檔、安裝包程序的下載，同時網站的訪問量也非常大，導致網站頻繁死機。 最多的一天死8次機，最短時間是在啟動之後5分鐘就down 機了。
先說網站服務環境：
操作系統： RHEL 5.5
應用服務器： WAS 7 單節點 。部署了3個應用分別是： cms 是網站， fileStorage_war 是附件目錄及下載應用，qyww 是數據查詢應用
數據庫：Orcale 11g
從環境的配置上來說，也可以看出比較大的問題，網站這種面向公眾的服務，其壓力可能比內網的業務系統的服務壓力還要大，這點由於我們設計上的疏忽導致了頻繁死機的重要原因之一。
其實一開始為什麼會這種設計，是因為我們做過網站的壓力測試，可以支持到4000的並發訪問，而且這個測試結果是由專門的測試公司做的，有了這個數據，我們項目組上對於網站這塊才沒太多的關注，在服務器配置上也沒做集群。而且這個網站又是一個政府事業部門的網站，按照慣例我們認為訪問的人不會太多。誰知道結果真是出人意料，內網的業務系統沒怎麼死機，反而外網的網站卻是頻繁死機。客戶因為這個，都打電話投訴到北京總部去了。
真是血的教訓啊。。。廢話不說了，直接說怎麼解決問題吧。
解決方案一：
由於時間比較緊，為了增加網站的穩定性和訪問量支持，就需要對網站的部署架構進行調整，增加服務器配置，同時採用集群的方式來支持網站應用。目前的單節點一旦出現問題，就會導致整個服務都停掉，如果採用集群的話再加上IHS做動靜分離，起碼從穩定性上能夠得到很大的保證。
這種方式應該是比較好的解決辦法，但是我們一提出來就遭到客戶痛罵。為啥呢？服務器的設備採購早就做完了，沒有服務器用了。因為客戶的預算也是要審批的，而且客戶也不會為了這個再去採購新的服務器，客戶對於我們以增加設備來解決問題的辦法也很反感，罵完一頓之後，連舊設備都不給一台，要求我們在現有設備基礎上解決問題，。
沒辦法這個方案就此無疾而終了，誰要我們一開始沒設計好呢，事後要再追加設備是沒這麼簡單的事情了。
解決方案二：
以下文章點擊率最高
Loading…