作者介紹

劉迪偉，就職于世界五***銀行。負責公司網銀業務系統的設計和交付，擅長并持續關注Java性能優化、DevOps等領域。

XX銀行網銀系統是一套全新的對公業務渠道類系統，經過兩年的建設，將逐步對外提供服務。

該系統融合了原來多個對公渠道系統，并發量是以前多個系統之和，吞吐量要求將大幅上升。為了使廣大對公客戶使用系統時獲得更快的響應時間體驗，項目組對系統進行了持續的性能測試和優化。這一過程中，形成了一套針對新建系統進行性能測試和優化的方法論。

該方法論包括測試環境準備、測試功能優先級、性能優化原則、常用性能指標及工具、工具使用方法、常見性能問題原因和優化方法，以及典型案例和進一步優化方法的討論。

由于系統已經開發完成，根據性能優化修改范圍盡可能小且不引入更多問題的原則，本文將只討論對系統進行局部優化的方法，而系統初始設計時為了提高性能而進行的設計不在討論范圍之內。

我們使用Linux操作系統，壓測工具為loadrunner，中間件版本包括IHS8.5.5.9、WAS8.5、IBMJDK1.7（IBM J9VM）、DB2V10、Redis3.2.3。

一、應用系統性能評價指標

• 響應時間：盡快的給用戶返回響應，體現系統處理請求的速度；

• 吞吐量TPS：每秒完成的事務數，體現系統處理能力；

• 并發性：業務請求高并發時，系統能否穩定運行；

• 擴展性：單機處理能力不足時，系統能否橫向擴展。

TPS = 并發用戶數 / 響應時間

二、常見性能監控指標及工具

1、操作系統監控指標及工具

主要監控指標：CPU、系統CPU、內存、磁盤IO、網絡IO、請求耗時。

常用命令：

• top –H –p pid：cpu負載監控，實時查看占用cpu高的線程；

• vmstat：系統負載監控；

• pidstat：cpu讓步式上下文切換監控，監控鎖競爭；

• iostat：磁盤利用率監控；

• nmon：監控cpu、內存、io使用率 ./nmon -f -t -s 2 -c 100 每2秒采集一次，共100次；

• netstat -anp|grep端口或IP|grep ESTABLISHED|wc -l：服務器連接數監控。

2、JVM監控指標及工具

• Jconsole，監控cpu、內存垃圾回收。

JVM啟動參數中增加：

-Dcom.sun.management.jmxremote.port=1088

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

• jvisualvm，cpu采樣、java方法耗時分析、jvm線程棧快照、監控cpu、內存垃圾回收。

CPU抽樣：

線程快照：

• jca457.jar，ibm javacore線程快照分析：

• ga456.jar，ibmjvm垃圾回收gc分析：

• ha456.jar，ibmjvm內存，heapdump分析，內存溢出時使用；

• TProfiler，cpu采樣、java方法cpu耗時分析，cpu高，響應慢時使用；

• JProfiler，cpu采樣、java方法cpu耗時分析，cpu高，響應慢時使用；

• OracleDeveloperStudio12.6-linux-x86，cpu采樣、java方法cpu耗時分析，cpu高，響應慢時使用。

三、性能測試前置條件

1、數據庫表數據量準確

要和生產數據量保持一致，至少一個數量級。數據分布盡量均勻。

2、測試環境和生產一致

測試環境機器配置、參數、代碼盡可能和生產保持一致（數據庫服務器硬件除外）。

3、合理確定并發用戶量

系統并發用戶量有多種算法可以估算：

• 平均并發用戶數：

  C=nL/T(n是考察時間內用戶登錄數，L是用戶平均在線時間長度，T是考察值時間長度)

  并發用戶數峰值：C’=C + 3*根號C

• 用戶總量/統計時間*影響因子：

  網銀用戶量100萬，根據2/8原則， 80%用戶在上午9點到11點，下午2點到4點之間登錄系統，每次登錄耗時1到1.5秒。則并發用戶為：

  1000000*0.8/4/3600*1.5=82.5，

  1000000*0.8/4/3600*1=55

• 根據系統用戶數計算：

  并發用戶數=系統***在線用戶數的8%到12%

• 根據TPS估計：

  C=（Think Time + 1）* TPS，

  網銀用戶思考時間10s，

  C=（10+1）* 3=33。

4、預估各功能交易量，確定壓測功能優先級

根據交易量從大到小排名，排名靠前的優先壓測。

5、設置性能問題認定標準

比如響應時間超過3s、TPS低于10、服務器cpu占用率超過70%、jvm堆內存使用100%、垃圾回收頻繁、網絡IO或磁盤IO達到瓶頸等……都可能是性能問題。

四、性能優化一般思路

1、找到性能瓶頸

性能瓶頸定義：導致系統TPS低、響應時間長、資源（CPU、內存、網絡）占用高等問題的關鍵程序模塊。提升該程序模塊的性能，可以大幅度改善性能。

常見的性能瓶頸原因包括：數據庫慢查詢SQL、日志打印、xml大報文解析和格式轉換、復雜業務邏輯、鎖競爭等。

2、如何找到性能瓶頸

• 使用LoadRunner給每個接口的增加事務，記錄其響應時間和TPS，最慢的那個接口往往是瓶頸；

• 分析慢交易的日志，查看是哪個操作耗時最長；

• 分析數據庫快照，看是否有執行較慢或者全表掃描的SQL；

• 通過Javacore查看線程正在執行的代碼，是大部分阻塞在IO上，還是大部分在進行計算。針對不同的問題，使用不同的分析工具。詳細內容可以看下一章節。

3、針對性能瓶頸進行合理優化

性能優化原則：

• 先優化瓶頸問題；

• 方案簡單，盡量不引入更多復雜性，盡量不降低業務體驗；

• 滿足系統性能要求即可，不引入新的bug。

五、常見問題及優化方法

1、SQL執行時間長

問題現象：系統響應時間長、數據庫cpu高。

問題原因：全表掃描、索引低效、排序溢出。

解決方法：

• 通過DB2數據庫快照查看執行時間長的SQL，查看該SQL執行計劃，在cost比較高的SQL上增加合適索引。要求所有大表SQL執行計劃的cost低于100，超過100的SQL要評審。對于排序溢出、可參考數據中心規范設置排序堆大小，規范中排序堆設置為AUTOMATIC。

• 制定數據庫表清理策略。根據數據的生命周期要求，對流水類的數據定期進行清理備份，不再長期保留。定期對全庫的表結構進行reorg、runstats操作，以提高索引效率。

排查方法：

• 獲得數據庫快照：db2 get snapshot for all on corpdb >gswyzfzzshpl1207.log

• 從快照中提取慢SQL，Toad查看SQL執行計劃

• Db2命令方式查看SQL執行計劃：db2expln -d corpdb -t -g -q "SQL語句"

• 執行計劃查看方法：自上而下查看cost***的分支，找到未走索引或索引使用不當的表

2、數據庫出現死鎖

問題現象：數據庫快照檢測到存在數據庫死鎖，或通過db2evmon -db corpdb -evm DB2DETAILDEADLOCK>dlock.txt生成死鎖監控文件，快照或監控文件中存在deadlock的情況。

問題原因：全表掃描、大事務、更新相同表記錄的SQL執行順序交叉等。

解決方法：縮短事務路徑長度，避免全表掃描。如果必須存在大事務，則更新相同表的SQL執行順序一致，并且堅決避免全表掃描。網銀系統指令發送功能全表掃描+全局大事務，導致數據庫死鎖。

排查方法：根據死鎖監控文件dlock.txt找到導致死鎖的SQL，以及該SQL持有的鎖，分析該SQL可能存在的問題。

3、線程阻塞在日志記錄上

問題現象：系統響應時間長、通過javacore查看很多線程阻塞在打印日志上。

問題原因：log4j1.x版本較低，性能較差；大報文日志多次輸出。

解決方法：

• 減少無效日志、刪除無用日志，減少大日志輸出。

• 升級log4j組件到log4j2，參考log4j2官方文檔，配置合理的日志緩沖區，采用高效的Appenders，比如RollingRandomAccessFile。但log4j2仍然采用同步日志，不采用異步日志。因為網銀系統日志量較大，異步日志隊列很快就滿了，如果單條日志存在大報文，還有可能導致內存溢出，因此不適合采用異步日志。如果日志量少（壓測產生日志的速度，低于日志寫入文件的速度），則可以使用異步日志，大幅提高性能。如果日志量較大，則不建議使用異步日志。

排查方法：

• JVM啟動參數中增加-XX:+HeapDumpOnCtrlBreak，壓測進行時，kill -3 pid 殺幾個javacore，使用jca457.jar工具打開并分析。推薦使用該工具，因為該工具可以對所有線程狀態進行統計，并生成餅狀圖，方便查看。

• 壓測進行時，使用jvisualvm獲取jvm快照，分析線程堆棧。

4、多線程并發問題

問題現象：采用合理的并發數壓測，系統出現邏輯錯誤、交易失敗或異常報錯。經查是由于對象中變量被異常修改導致。

問題原因：系統中全局對象中的類變量或全局對象，被多個線程修改。

解決方法：排查系統中所有持有全局對象或類變量的代碼，檢查其全局變量是否可能被多個線程并行修改。

修改方法：

• 將全局變量轉成方法內的局部變量；

• 對全局變量進行同步控制比如syncronized代碼塊，或者java.util.concurrent鎖。

排查方法：并發問題很可能是由全局變量或者對象導致，準確識別全局變量，通過閱讀代碼找問題。建議應用梳理所有可能存放全局對象的代碼，統一管控，或者把所有全局對象放到一個類中，方便管理。

5、打開了太多文件

問題現象：采用合理的并發數壓測，交易失敗，或后臺日志報錯：To many open files。

問題原因：

• 讀取配置文件或者業務數據文件后，未關閉文件流；

• /etc/security/limits.conf中***打開文件數配置過小。

解決方法：

• 使用lsof –p pid 命令查看進程打開的文件，如果大部分文件都是同一類型的文件，說明可能未關閉文件流。找到打開文件的代碼，關閉文件流即可。

• 如果不存在未關閉文件流的問題，且業務本身就需要處理大量文件，則修改/etc/security/limits.conf文件如下內容：

* hard nproc 10240

* soft nproc 10240

6、內存泄漏

問題現象：JVM內存耗盡，后臺日志拋出OutOfMemeryError異常 ；

問題原因：內存溢出問題可能的原因比較多，可能是全局的List、Map等對象不斷被擴大，也可能是程序不慎將大量數據讀到內存里；可能是循環操作導致，也可能后臺線程定時觸發加載數據導致。

解決方法：對于ibmjdk純java應用，在jvm啟動時設置-XX:+HeapDumpOnOutOfMemory Error參數，會在內存溢出時生成heapdump文件。使用ha456.jar工具打開heapdump文件，分析大對象是如何產生的。

當然，在heapdump中對象類型可能只是List這種結構，看不出具體哪個業務代碼創建的對象。此時要分析所有的全局對象，列出可疑的List或Map對象，排查其溢出原因。

全局對象、引用的初始化、修改要慎重。建議應用梳理所有可能存放全局對象的代碼，統一管控。

7、JVM垃圾回收頻繁

問題現象：top –H –p pid命令查看，GC Slave線程CPU占用排名始終為前三名，同時Jconsole查看jvm內存占用較高，垃圾回收頻繁。使用ga456.jar分析gc日志，查看gc頻率、時長。

打印gc日志的方法：在jvm啟動參數里增加-verbose:gc -Xverbosegclog:/usr/ebank/ logs/cobp/gcdetail.log

問題原因：高并發下，內存對象較多，jvm堆內存不夠用 。

解決方法：擴大堆內存大小–Xmx2048m –Xms2048m。

8、CPU高

問題現象：50并發壓測，監控工具顯示bp、前置CPU占用90%以上。

問題原因：業務處理中存在大量CPU計算操作。

解決方法：采用更高效的算法、數據結構替換原來消耗CPU的代碼，或者采用新的設計繞過瓶頸代碼，比如查找數據的邏輯，可以把List改為Map，以空間換時間；比如用Json報文替換XML報文，提高傳輸、解析和打印日志的效率。

導致Cpu計算資源高消耗的代碼：報文格式轉換、加解密、正則表達式、低效的循環、低效的正則表達式。

排查方法：

• 壓測進行時，使用jvisualvm工具遠程連接應用，點抽樣器àCPU，點快照生成線程快照。采樣一段時間后，抽樣器會顯示各個方法占用cpu時間，可以針對CPU時間占用高的方法進行優化。

• 使用tprofiler，jprofiler，OracleDeveloperStudio12.6-linux-x86工具分別分析消耗CPU時間長的方法，以上工具分析結果可能有些差別。針對CPU計算耗時最長的方法進行優化。

9、批處理時間長、數據庫逐筆插入緩慢

問題現象：大批量數據（10萬條以上）更新或插入數據庫，耗時較長。

問題原因：批量數據處理時，如果逐條更新數據庫，則會存在大量網絡io、磁盤io，耗時較長，而且對數據庫資源消耗較大。

解決方法：

• 采用java提供的batchUpdate方法批量更新數據庫，每1000條commit一次，可大幅提高數據更新效率。

• 單線程改成線程池，并行處理，充分利用多核CPU，通過數據庫或者其他同步鎖控制并行性；增加緩沖池，降低數據庫或磁盤IO訪問頻次。

10、數據庫CPU高

問題現象：后臺指令發送滿負荷工作時，數據庫CPU高。

問題原因：后臺指令發送線程每次對全量查詢結果排序，結果集很大，然后取一條記錄；索引區分度不高，滿負荷執行時；查詢頻率很高；壓測顯示，并行發送指令的后臺線程越多，數據庫CPU越高，效率越低。

解決方法：

• 去掉ORDER BY，增加索引后，效果不明顯。因為結果集大和查詢頻繁兩個問題沒有解決，因此考慮使用設計新的方案。

• 新方案：設計指令發送線程池，生產者線程每臺任務服務器只有一個線程，負責查詢待發送指令，每次查詢50條指令。每條指令包裝成一個Runnable對象，放進ThreadPoolExecutor線程池，線程池大小參數設置為100或200。每當線程池滿時，生產者停止生產指令，休息15秒后繼續。消費者線程即線程池里的線程，參數設置為4，8或12（和不同指令類型的指令數據量成正比）。

改進后的方案，數據庫CPU降到10%一下，發送效率單機提升6倍，且可線性擴展任務服務器。

11、壓測TPS曲線劇烈下降或抖動

問題現象：50并發壓測，TPS曲線正常應該是平緩的，波動不大，如果突然出現劇烈下降，并且短時間內無法恢復，則可能存在問題。

問題原因：一般是由于前置或bp的jvm進行垃圾回收，或者日志記錄磁盤滿導致的。

解決方法：如果不是特別劇烈的波動或者TPS曲線下降后長時間不反彈，則可以忽略該問題。否則，需要分析曲線下降的時刻，系統當時正在發生的事情。可以通過top命令監控當時CPU占用比價高的線程，也可以kill -3 pid殺javacore來查看線程堆棧。

六、優化案例

1、網銀系統基本情況

1） 壓測環境系統架構

壓測環境不包括F5，只有1臺WEB、1臺前置（應用服務器）、1臺BP（業務處理服務器）、1臺DB、1臺Redis服務器。

2）客戶請求鏈路：

客戶端壓力機-〉Web-〉PRE-〉BP-〉DB2 ；

客戶端壓力機-〉Web-〉PRE-〉BP-〉擋板服務器（模擬后端服務方）。

3）系統特點：

• 用戶、賬號權限校驗較多。

  對公業務典型場景：經辦、審核、查詢、下載、批量。用戶權限通過業務鏈控制。

• 接口調用較多，且由前端組合調用接口。

  前后端分離，前端通過調用一個個接口來完成業務。接口粒度較細。登陸、支付轉賬經辦需要15~19個接口完成一次交易。

• 強一致性、高可用性。

  資金交易系統，一致性需要通過數據庫來保證。

4）網銀登錄壓測曲線

2、數據庫消息隊列案例（指令發送隊列）

需求是：對于需要異步處理的交易指令，需要設計一個基于數據庫的消息隊列，我們稱之為指令發送隊列。該隊列既要滿足服務器的性能約束，又要滿足每日處理交易量的要求。

1）優化前處理過程

后臺任務每次從數據庫指令表中排序并取最早的一條指令，獲取該指令的詳細交易信息，組裝成報文并調用接口發送后臺核心系統。

在壓測環境下，該方案如果配置一個后臺任務，無法達到系統設計的指令處理速度；如果配置多個后臺任務，則會導致數據庫CPU占用較高，影響其他聯機業務的開展。

2）優化后處理過程

每臺后臺任務服務器配置一個生產者任務，20個消費者任務。

生產者任務一次取100個（可配置）指令，依次分配給20個消費者任務中空閑的任務，消費者任務獲取指令詳細信息，并組裝報文后發送后臺核心系統；生產者任務如果發現無空閑消費者任務，則等待15s后重新判斷。

此方案顯著降低了數據庫CPU負載，合理利用了應用服務器的并發能力，處理效率大為提高，以上線程數和每次獲取的指令數可以配置。

指令發送線程池模型圖：

3、數據庫死鎖案例

1）死鎖問題現象

當多臺任務服務器同時運行大額指令發送后臺線程，即多個生產者線程并行更新數據庫指令表時，數據庫快照檢測到存在數據庫死鎖，或通過db2evmon -db corpdb -evm DB2DETAILDEADLOCK>dlock.txt 生成死鎖監控文件，快照或監控文件中存在deadlock的情況。

DB2數據庫有自動解除死鎖功能，死鎖超時時間默認為10s，數據庫會隨機選擇一個死鎖事務kill掉。本案例由于是后臺任務，所以用戶感覺不到死鎖；如果是聯機交易，一個用戶會發現交易失敗，另一個用戶交易成功，但是會感覺交易變慢。指令發送后臺任務模型詳見下一章節內容。

2）數據庫死鎖發生原理

兩個不同的數據庫事務使用排它鎖鎖住了同一張表的不同行記錄，并且互相等待讀取對方鎖住的行記錄。

3）導致死鎖的可能原因

全表掃描、大事務、事務之間對死鎖訪問順序交叉等。

4）死鎖問題排查過程

Step1：分析數據庫快照和死鎖監控日志，查看導致死鎖的SQL，定位問題SQL。

Step2：問題SQL不存在事務之間對死鎖訪問順序交叉的情況，當時尚不清楚程序中的全表掃描、大事務可能會導致死鎖，因此做了以下實驗：

• 模擬問題SQL在兩個不同的數據庫客戶端執行SQL，查看數據是否更新成功。

• 完全按照源程序的SQL邏輯執行驗證：

UPDATE ( SELECT BP_SRVR_IP FROM ${tableName} WHERE TSK_STAT='TODO' AND ( BP_SRVR_IP IS OR BP_SRVR_IP='') AND PRTY =? AND eff_tm <= CURRENT TIMESTAMP FETCH FIRST 50 ROWS ONLY WITH RS) t SET BP_SRVR_IP=?

• 不加索引，A事務在R上加了X鎖，B事務無法在任何記錄上加X鎖，B事務會等待A事務提交后再加鎖。

• 增加索引，A事務在R記錄加了X鎖，B事務在S記錄加X鎖，互不沖突。

Step3：實驗發現查詢SQL增加with RS隔離級別，查詢效率會更高。當A事務已對記錄R加X鎖，B事務掃描到R記錄時，如果是CS隔離級別，B事務會自動退出，返回空結果集；如果是RS隔離級別，B事務會等待A事務完成后，跳過R記錄，對符合條件的R+1記錄加X鎖。

Step4：PRTY字段增加索引，沒有出現死鎖問題；或者不加索引，維持全表掃描不變，大事務改成小事務后，也沒有出現死鎖問題。

5）兩點經驗

• 需要提前熟悉DB2鎖的種類和作用，隔離級別的種類和作用，表鎖和行鎖發生的條件。比如，全表掃描時，DB2會在整個表上加表級鎖；如果是增刪改操作，會加表級排他鎖。

• 在不清楚死鎖原因時，或者不了解鎖的機制和隔離級別機制時，不同隔離級別下SQL的影響范圍，可以在數據庫客戶端工具上進行手工小實驗，驗證數據庫機制以及猜想。

七、后續提升網銀系統性能備選方法

1、增加緩存的使用

• 對于讀多寫少的數據，可以加載到分布式緩存，降低數據庫壓力；

• 目前已經將部分參數和錯誤碼數據放到分布式緩存，后續謹慎提高緩存使用率，降低數據庫壓力。

2、精簡BP日志。刪除交易訪問記錄日志表的操作。

3、合并、精簡接口數量，前端緩存數據。