記錄一次出差廣東對中介軟體效能最佳化的完整報告

某某系統效能分析最佳化報告

一、背景

        2014年1月份以來XX系統多次頻繁出現訪問量上去後，系統查詢SQL語句提交到oracle資料庫進行查詢未及時返回時，很容易出現後台線程掛起，而XX系統並發數較高達到每一個節點200多個串連，總串連數達到800多，WAS線程池未能及時釋放，最終導致線程池耗盡，需要定期重啟WAS才能解決；當前利用營運監控管理系統每隔30分鐘監控，無法訪問時簡訊警示，然後人工重啟，基本上一周要重啟兩到三次，同時分析中介軟體日誌對Oracle資料庫進行最佳化，但是效果不佳。

        公司高度重視使用者、項目組反饋的情況，在公司內部安排資深研發人員、系統架構師分析現場項目組發回的系統日誌，中介軟體日誌，排查系統可能存在的隱患點，並安排資深技術專家到現場進行排查，解決系統效能問題。

       2014年4月14人日我到現場，與XX單位李主管、公司分公司總經理曾某、現場項目組負責人許某就目前XXX系統存在的效能情況做了溝通，收集系統存在效能問題現象、可能的規律，主要有以下方面：

      1、系統運行一段時間後綜查系統訪問變慢，訪問出錯，見1-1。

圖1-1

2、 當訪問量急劇增長時出現，JDBC資料來源串連上升很快，系統請求變慢，回應時間變長，系統查詢長時間沒有響應，如1-2。

圖1-2

     3、伺服器消耗CPU資源達到97%、記憶體資源消耗達到50%，見1-2。

圖1-3

       上述三種情況都需要通過人工重啟中介軟體才能解決。

二、原因分析過程

        我到現場後通過分析XX系統中介軟體日誌、伺服器參數設定；對近幾年的系統訪問日誌按照年、月、日等不同角度做了對比，通過資料可以分析得出XXX系統的訪問量呈線性增長，訪問量一直都非常高，綜合以上幾個因素初步定位了系統引起宕機的主要原因，在使用者數高並發時，中介軟體WebSphere線程池非常繁忙，引起JVM記憶體回收不能及時有效處理，最後導致XXX系統中介軟體線程掛起宕掉。

      （一）、檢查伺服器、中介軟體設定並進行參數最佳化

1、檢查作業系統紅旗Linux的核心參數設定，核心參數中最大可用記憶體限制為2G，修改核心參中最大可用記憶體為32G。

2、查看分析近一周中介軟體日誌，日誌主要表現在當系統出現高峰訪問時有部分資料來源因連線逾時而關閉。

3、查看中介軟體系統配置，修改JVM的最小堆最大堆分別由1024M、2048M改為2048M、4096M。

4、更改應用伺服器會話管理由1000增大到2000，逾時時間設定由30分鐘縮小為10分鐘，加快未使用資源的釋放。

5、統計各個資料來源所引用的查詢方案使用較高的，增加資料來源的串連池最小以及最大串連數。

6、調整資料來源的逾時設定，加快GC回收精準度。 

（二）、系統運行監控、日誌分析，精確定位問題原因

         按照上述分析思路對XXX系統進行監控，驗證分析結果。

        2014年4月15日-2014年4月16日，兩天對XXX系統的運行情況進行跟蹤分析，並增加一個概要節點運行，增加系統的壓力的分擔，監控結果顯示：

1、當業務高並發時（上午9:30-11:30，下午14:30-17:30），XXX系統都是在消耗資產庫資料來源(JDBC/XXX)的串連池，串連池資源釋放非常慢。

 2、因已對中介軟體JVM虛擬機器記憶體進行修改加大，並且又增加了一個was執行個體運行，目前系統尚穩定。

3、系統資源消耗情況，CPU資源消耗很低，記憶體消耗16G左右，沒有太大波動。

 4、修改負載平衡器的負載策略，改變原來的源IP最短響應負載策略為輪詢負載策略，5個節點目前訪問數量基本一致。

 5、與研發人員溝通分析是否程式碼存在記憶體泄露或串連未關閉的情況。

 6、查看中介軟體日誌發現部分方案存在配置問題，查詢會報錯，主要查看117節點，而117節點在16、17日兩天中介軟體的JDBC資源一直得不到釋放。

（1） XXX方案的分段代碼分段不能查詢，SQL 拼接缺少AND符號；

（2）VW_001表的XXXZHM欄位不存在；

（3） VW_002的XXXHM欄位不存在；

（4） VW_003的XXX_ID欄位不存在；

（5）VW_004的XXZH欄位不存在；

（6） VW_005的XXXSFHM欄位不存在；

              以上是日誌中報錯的一部分，現場還需要對整個日誌分析，直到所有的方案都不會報錯。

              綜合以上分析，原因基本定位，採取最佳化措施並對剩餘節點重點處理了以下措施：

（1） 修改伺服器的核心參數對記憶體的限制，4台伺服器全部修改。

（2）修改中介軟體的JVM虛擬機器大小，最小堆和最大堆分別為2048M、4096M。

（3） 調整硬體負載平衡器的負載策略，設定10個串連為起點進行輪巡的負載策略

（三）、綜合分析其他三個單位的效能問題

 1、A單位經觀察主要原因是部分資料資源的串連不能釋放，長時間運行後會出現堆積。

 2、A單位業務高峰期觀察應用伺服器JDBC繁忙數最高20個，CPU達到96%以上，記憶體佔用達到22G，磁碟IO不明顯，僅佔用很小的200kB/s，經過業務高峰期後，系統能回複業務低穀時的資源佔用水平。

 3、B單位主要是因為網路原因造成以及資料來源串連不能得到釋放。

 4、C單位查看了一個節點，主要原因也是因為資料來源的串連不能得到釋放。

三、A單位系統及B、C單位系統效能最佳化處理措施 

1、對每一台伺服器查看中介軟體日誌，根據出錯的資訊對出錯的方案進行調整。【非常重要】

2、調整中介軟體的JVM虛擬機器記憶體，修改為初始堆2048 M、最大堆4096 M（前提是作業系統沒有限制）。

一台伺服器記憶體為32G，建議先增加一個概要檔案（從目前A單位情況來看，伺服器的CPU在業務高峰期壓力較大）。

3、設定會話管理中的記憶體溢出，禁止溢出，設定逾時時間為15分鐘。

4、修改記憶體會話由1000增加到2000。

5、修改應用程式的會話個數由1000增加到2000，並設定禁止記憶體溢出

6、修改資料來源的逾時時間，針對應用訪問量大伺服器設定連線逾時、收集時間、未使用逾時、時效逾時分為60、60、60、50，針對訪問量中等的設定為120、120、120、300，針對小訪問量設定為180、180、180、240。

7、修改線程池的default的最小大小20、最大大小100，webcontainer的最小30、最大150。(A單位系統中介軟體default的最小大小20、最大大小100，webcontainer的最小30、最大200) 

8、開啟Container Service的ORB按引用傳遞服務，開啟web容器的servlet快取。

9、修改後監控應用系統在業務高峰期的JDBC串連，並分析中介軟體日誌是否存在錯誤記錄檔。

10、建議對中介軟體的補丁進行安裝，最新版本補丁一定程度上在代碼層面做了最佳化，websphere中介軟體6.1最新補丁版本號碼為6.1.0.47, websphere中介軟體6.0的最新補丁版本號碼為6.0.2.43。