性能調優事例

 

1 腳本是優化的     
 1.1對於BS結構的腳本錄製 儘可能將一些圖片請求 或者重複請求 或者是 動態刷新頁面的請求所有幹掉      
 1.2 函數使用 ：正式跑場景的時候將調試函數屏蔽 lr_out_message   lr_log_message   lr_error_message 等  關聯函數的參數選擇 ---- to_date to_char    
2.客戶端：壓力機自己優化  其目的是別讓壓力機端口存在堵塞現象    
3.網絡  看網絡存不存在丟包    
4.應用服務器：sysconf   sysctl -a  > sysctl.txt   、與數據庫鏈接配置文件     
  應用日誌步驟： 看耗時狀況    
5.中間件 :tuxedo （域服務器配置） weblogic  JDK   MQ  Congnos  nginx   F5 等      
      
6.數據庫 ：Oracle   DB2    infomix 等    
    
7.架構:    
    
--------------------------    
參數化策略：每次迭代、每次出現、只取一次    
        順序、隨機、惟一
    
#AIX系統：    
#1.判斷內存不足：svmon -G:   virtual值大於size,則代表物理內存不足，換頁不可避免，只能在硬件上升級物理內存或者配置用戶應用，經過減少應用對內存的需求量來解決。    
                 vmstat:收集內存使用數據和換頁數據；fre，avm:表示系統工做所需的頁面數；avm > fre,代表換頁。    
                 lsps:收集換頁空間的使用狀況。    
    
    
---------------------內存泄漏產生的緣由-----------------------    
一、分配萬內存後忘記了回收    
二、程序代碼有問題，形成沒有辦法回收    
三、某些API函數操做不正確，形成內存泄漏    
    
---------------------------注意：-----------------------------    
若是重啓機器後，cache沒有被釋放，可進入/proc/sys/vm中使用echo 2 >drop_caches命令釋放cache。    
    
--------------------------------------------------------------    
HTTP錄製協議關聯：    
insert--->搜索web_reg_save_param進行關聯，關聯函數要放在參數字段語句上面，打印日誌函數要放在參數字段語句的下面。    
登錄的關聯最好是登錄的帳號或密碼    
    
--------------------------------------------------------------    
xml格式轉換：    
一、視圖中的選擇XML格式    
二、格式中選擇XML轉換格式    
    
編寫測試報告時問題分析：    
一、對問題分析要深刻，排除自身的影響    
二、要注意格式的排版    
    
--------------------------------------------------------------    
統計當前目錄下（包括子目錄）全部文件個數    
ls -lR |grep "^d" |wc -l    
    
--------------------------------------------------------------    
java 程序的項目都須要監控VmRss、Vmsize    
VmRss:虛擬內存駐留集合大小。這是駐留在物理內存的一部分，它沒有交換到硬盤。它包括代碼、數據和棧。    
Vmsize:虛擬內存大小。整個進程使用虛擬內存大小，是VmLib、VmExe、Vmdata、Vmstk的總和。    
    
---------------------------------------------------------------    
Tuxedo腳本調試：    
一、瞭解服務器端Tuxedo版本，本地控制機安裝Tuxedo客戶端，配置環境變量    
二、瞭解WSL訪問方式（IP:Port）    
三、瞭解研發使用的Tuxedo服務名、數據緩衝類型（如：CARRAY、FML32等）、緩衝區長度（如1024*1024*3）    
四、瞭解這個緩衝區類型的緩衝結構（包括哪些字段，這些字段的屬性（數據類型、數據長度等），以及這些字段要放置什麼數據，是任意數據仍是指定的死數據）    
五、瞭解報文（報文長度、內容、詳細信息；哪些數據須要作參數化；調研報文的格式，是否經過在腳本中組裝報文，是否能夠經過從報文文件中獲取報文）    
六、瞭解報文發送後服務器返回的數據內容、長度等，用做在腳本中判斷事物是否成功    
    
---------------------------------------------------------------    
三層架構:    
客戶端（表現層） 中間件服務層（業務邏輯層）  數據庫服務器層（數據層）    
應用weblogic中間件的系統通常採用的B/S架構，絕大部分採用HTTP協議，少許的系統用JAVA編寫的客戶端，使用的是RMI協議，或J2EE裏的協議。    
    
-----------------------------------------------------------------    
配置host的路徑： C:\windows\system32\drivers\etc    
    
----------------------------------------------------------------    
正則表達式：    
代碼   說明    
.      匹配除換行符之外的任意字符    
\W     匹配字母或數字或下劃線或漢字    
\S     匹配任意的空白符    
\d     匹配數字    
\b     匹配單詞的開始或結束    
^      匹配字符串的開始    
$      匹配字符串的結束    
    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------    
---------------------------------------------------------------項目調優事項------------------- -------------------------------------------------------------------------------    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------    
    
1、ECIF    
    
一、問題描述：性能測試組在生產環境對ECIF系統進行性能測試，截止目前發現的問題主要是10併發過程當中發現ESB應用服務器CPU資源消耗太高，在70%左右，而且當中sys%佔比較高佔資源消耗的50%。    
   問題分析：經分析一個是CPU資源不足，還有一個緣由是應用日誌輸出過多引發的。    
   問題解決：應用服務器CPU增長至8C，減小了日誌中冗餘內容的輸出。    
    
二、問題描述：ECIF高併發時出現交易大量報錯現象。    
   問題分析：交易發送處理完，斷開鏈接，可是未收到客戶端的端口關閉動做，致使大量端口被佔用，端口資源被耗盡。    
   問題解決：優化了tcp鏈接參數，調整了系統控制文件（sysctl.conf）裏的端口複用和快速回收參數，增長配置參數詳細以下:net.ipv4.tcp_syncookies = 1    
                                                                                                                  net.ipv4.tcp_tw_reuse = 1    
                                                                                                                  net.ipv4.tcp_tw_recycle = 1    
                                                                                                                  net.ipv4.tcp_fin_timeout = 30    
    
三、問題描述：性能測試組在生產環境對ESB系統進行性能測試，10併發過程當中發現ESB應用服務器CPU資源消耗太高，在80%左右。    
   問題分析：經技術人員分析緣由是應用日誌輸出內容過多，致使cpu資源被大量消耗引發的。    
   問題解決：1．優化異步寫數據庫日誌線程池,將JMS隊列線程數由20調至50個線程,同時修改了代碼處理邏輯。    
             2．優化內部服務控制處理流程。    
             3．關閉非必要輸出日誌。    
    
2、財務    
    
一、問題描述：發票認證結果交易容量測試過程當中，隨着併發數的梯度增長，應用服務器CPU資源消耗和交易TPS無明顯增加，交易響應時間明顯變長。    
   問題分析：經與技術人員調試分析，該交易因爲業務須要，憑證號碼必須是按照順序生成，憑證號生成過程當中採用單線程方式，所以致使該問題和現象。    
   問題解決：  技術人員分析，要實現順序生成憑證號的業務規則只能採用單線程方式，而且發票認證業務屬於審批類交易，在生產上屬於權限較高的業務，並不存在高併發高壓力的問題，目前測試的結果，從響應時間和TPS以及資源消耗狀況來看，都能知足從此生產須要，故經項目組贊成該問題暫不處理。    
    
二、問題描述：在對F5可靠性測試過程當中，當停掉一臺應用服務和重啓服務後，TPS未能恢復到最初水平，交易一直報錯，錯誤提示：發票代碼：XXXXXX,發票號碼XXXXXX，數據已經被鎖定，請等待；而且出現終止測試場景，曾被停掉服務的應用服務器cpu資源仍然佔用100%現象。    
   問題分析：經與技術人員分析，交易在執行過程當中，程序須要對該數據進行加鎖處理，當交易完成後再釋放鎖，但未考慮執行交易過程當中出現交易中斷，釋放鎖的處理邏輯，所以形成死鎖現象發生。    
   問題解決：取消了程序中加鎖的代碼。    
    
3、新櫃面、無紙化    
    
一、問題描述：執行穩定性測試，在info級別下會記錄大量的日誌，沒法支撐24小時，另外應用服務器的SWAP分區因內存不足被逐漸消耗。    
   問題分析：硬件資源內存不足致使。    
   問題解決：將日誌級別修改成error級別，服務器的SWAP分區不在被佔用。     
    
二、問題描述：執行單交易測試，場景在10用戶併發下執行2小時30分鐘，隨着交易時間愈來愈長，TPS從最高91筆/s降到最低61筆/s，呈現明顯降低的趨勢；響應時間從最低0.108s上升到最高0.16s,呈現明顯上升的趨勢；發現數據庫CPU資源使用率也愈來愈高，呈現明顯上升趨勢，CPU資源使用率從最低65.8%上升到最高91.5%；數據庫磁盤I/O基本維持在30%左右，呈現逐步降低的趨勢。    
   問題分析：經過awr報告分析其中一條sql：select ELECDOCDATE, ELECDOCNO from ab_elec_doclog where CHANELDATE = :1 and CHANELCODE = :2 and VOUTYPE = :3 and PRINTNO = :4 and STATUS = '1'佔用65%以上的cpu時間，而且該sql執行了全表掃描。    
   問題解決：項目組優化了ab_elec_doclog表的索引字段，並將索引使用的表空間從系統表空間移到用戶表空間。    
    
三、問題描述：執行單交易測試過程當中，發如今10用戶併發下，TPS150，數據庫I/O僅7M/秒，但數據庫服務器磁盤利用率高達50%以上，當加壓到20併發時，磁盤利用率就超過80%。    
   問題分析：經過awr報告分析目前每成功一筆交易數據庫須要commit 4次，當前10個併發tps爲150，就意味着數據庫一秒鐘commit次數達到150*4=600次，所以致使磁盤利用率和cpu太高的現象出現。    
   問題解決：項目組調整了數據庫Commit次數，由原來的4次調整爲3次，數據庫的磁盤繁忙率在必定程度上獲得了緩解，可是當TPS超過300仍然會出現該狀況。    
    
4、黑名單    
    
一、問題描述：執行負載測試，當併發用戶數從50增長到100時，TPS未相應增長仍然保持在300左右，應用服務器和數據庫服務器的cpu使用率也無明顯變化，僅交易響應時間從0.15秒增加到0.3秒左右。    
   問題分析：經屢次測試調試，發現日誌對交易響應時間和TPS影響較大，當日志級別爲error時，50併發tps可達2000；日誌級別爲info時，50併發tps僅300。    
   問題解決：優化應用程序中日誌處理邏輯，去除了冗餘日誌的輸出並把沒必要要的日誌輸出調成了debug，必要的日誌調成info級別。    
    
5、統一回單    
    
一、問題描述：單交易基準測試從場景發現回單打印交易在1vu下執行100次迭代，平均響應時間達到4.5秒、回單預覽交易平均響應時間達到2.7秒，超過性能指標2秒，且數據庫CPU大於20%。    
   問題分析及解決：有執行效率太低的sql致使數據庫CPU偏高，響應時間較長。優化sql，增長索引，問題得以解決。附優化後sql：    
    
二、問題描述：單交易負載測試20vu併發，數據庫CPUwait%較高，磁盤佔用率超過80%。    
   問題分析及解決：代碼中有記錄日誌的操做，併發壓力時數據庫頻繁寫日誌，致使磁盤IO太高。關閉數據庫日誌操做，問題得以解決。    
    
三、問題描述：單交易負載測試20vu併發，數據庫CPUsys%較高，致使CPU利用率達到100%。    
   問題分析及解決：未找到緣由。更換數據庫後，問題獲得解決    
    
四、問題描述：容量測試增長併發數後，系統交易平均響應時間逐漸上升，系統處理能力逐漸降低，應用及數據庫各項資源指標無明顯變化。    
   問題分析及解決：1.壓力上不去：接收報文時將報文map轉換成object這一步驟時，方法性能不高，壓力卡在這一步。後改動mapToObject方法，提升該方法性能，壓力提升。    
                   2.第二次壓測時，發現明細帳打印響應時間很長，發現是每次明細帳打印時都編譯模板，形成性能過低。修改打印方法，只編譯一次，之後打印都不編譯。性能提升，響應速度下降。    
    
五、問題描述：簽約交易單交易併發測試過程當中，數據庫磁盤利用率較高超過80%。    
   問題分析及解決：簽約交易每發生一筆就會對數據庫進行兩次insert操做和四次select操做，且每執行一次後都要完成一次commit操做，以上均爲正常的業務邏輯操做，沒法進一步優化；對壓力測試場景增長1ms pacing後，20vu併發複測，數據庫磁盤利用率降低到48.9%，平均響應時間爲19ms，TPS爲628.032筆/秒。    
    
6、外部數據管理平臺    
    
一、問題描述： 20個併發執行我的客戶信用報告查詢申請、我的客戶信用報告查詢詳細信息混合場景10分鐘，報「接口運行時異常」錯誤，且響應時間比較長。    
   問題分析：性能測試環境未鋪好，本次是對開發環境進行試壓，版本穩定後打包至測試環境。項目組查看後臺並通過分析發現，最大線程數是20 ，致使線程池堵塞；計費模塊中費用統計同步，配額機制主要統計接口使用次數存在Update操做，致使響應時間比較高。    
   問題解決：項目組調整了以下內容：    
            1.最大線程數由20調爲1000；    
            2.計費模塊中費用統計由同步調爲異步；    
            3.配額機制主要統計接口使用的次數取消了Upadate操做。    
    
二、問題描述：執行我的客戶信息報告查詢詳細信息交易20併發單交易聯調測試，報「接口運行時異常」。     
   問題分析：項目組查看後臺發現費用流水錶被刪。    
   問題解決：項目組重建了費用流水錶 。    
    
    
7、網聯繫統    
    
一、問題描述： 執行身份認證及簽約交易40併發、60併發單交易試測，響應時間由0.4秒增加至0.55秒，TPS保持在70左右，應用服務器CPU使用率在45%左右，沒有明顯增長，最大TPS只能達到250左右TPS，資源使用率在60%左右。    
   問題分析：一、項目組分析日誌查看日誌打印時間間隔，發現日誌打印的時間慢。    
             二、根據日誌打印定位代碼，查看代碼塊，對代碼塊進行分析，而後優化接收線程池。    
             三、根據日誌狀況進行打印日誌輸出，而後再進行壓力測試，發現不打印日誌tps可以達到正常值。    
             四、根據不打印日誌狀況優化日誌輸出方式，採用log4j輸出日誌。    
             五、再進壓力測試發現單機tps可以達到350。而後再進行log4j版本升級。升級到log4j 2.0版本。     
             六、再進行壓力測試，發現單機tps可以達到400以上。    
    
   問題解決：一、優化接收線程池；    
             二、採用log4j 2.0版本輸出日誌。    
    
二、問題描述： 進行容量測試壓測，發現160併發，tps達到400左右，數據庫磁盤IO達到70%左右，繼續增長併發至180，tps仍是維持在500左右,數據庫磁盤IO達到80%左右。     
   問題分析：項目組查看後臺發現是數據庫的配置不足致使的，如今的配置是4C4G,生產上是8C16G，故配置提高至8C8G；數據庫版本如今是11g，生產上版本是12C，故版本升級至12C,相關內核參數作了調整，問題獲得解決。    
   問題解決：數據庫配置由4C4G提高至8C8G，版本由11g升級至12C，數據庫內核參數也作了調整，具體oracle 11g內核參數見附件一，oracle 12C 內核參數見附件二。    
    
三、問題描述：進行120併發400TPS的穩定性試壓，執行到6小時左右時，數據庫CPU達到100%，磁盤IO也達到100%，且數據庫內存存在泄漏問題，執行至12小時時，報大量「系統異常錯誤」，後臺報「【信息：表：【EPCC_MSGRGSTR】,數據入庫失敗,執行存儲過程：PRO_EPCC_MSGRGSTR_01執行失敗java.sql.SQLException: ORA-01653: 表 EPCC.EPCC_MSGRGSTR 沒法經過 8192 (在表空間 EPCC 中) 擴展】」錯誤。    
   問題分析：一、項目組查看後臺發現系統表空間不足，現有是100g磁盤，沒有創建表空間，項目組從新創建表空間，磁盤空間擴至300G。    
             二、打印AWR報告發現SQL「select trxctgy from epcc_msgrgstr where rpflg=:1 and INSTGID=:2 and trxid=:3 」 耗時比較長，項目組通過分析，發現索引「EPCC        ID1_EPCC_MSGRGSTR  Normal  RPFLG, INSTGID, TRXID  N  Y  N  N        tablespace epcc pctfree 10 initrans 2 maxtrans 255 storage ( initial 64k next 1m minextents 1 maxextents unlimited )」 在數據導入數據庫時未及時生效。    
   問題解決：一、項目組從新創建表空間，表空間由32G擴充至160G；    
             二、從新創建了索引「EPCC   ID1_EPCC_MSGRGSTR     Normal      RPFLG, INSTGID, TRXID    N     Y     N     N      N     tablespace epcc pctfree 10 initrans 2 maxtrans 255 storage ( initial 64k next 1m minextents 1 maxextents unlimited )」。    
    
    
-------形成數據庫繁忙的緣由------    
一、對數據庫的使用過於低效：錯誤的查詢設計、糟糕的應用程序邏輯、對於數據訪問框架的配置不正確    
二、糟糕的數據庫設計與數據結構：表的關聯、緩慢的存儲視圖、缺失的或錯誤的索引、過時的表統計信息    
三、不恰當的數據庫配置，例如：內存、磁盤、表空間、鏈接池等