1.xx系統真實調優經歷
壓測環境系統架構圖如下：
壓測結果
|
線程數 |
TPS |
ART |
APP_CPU |
APP_MEM |
|
150 |
1551 |
0.094s |
57.377% |
16.522% |
|
200 |
1562 |
0.125s |
59.862% |
16.624% |
|
300 |
1572 |
0.186 |
57.108% |
16.643% |
150併發發用戶,TPS:1551筆/秒，平均響應時間:0.095秒 逐漸增加併發至300,TPS:1572筆/秒，幾乎無增長且平均響應時間呈增長趨勢，期間比較不同併發下各服務器的CPU消耗情況基本一致,且均未達到系統瓶頸。
分析原因
抓取線程快照：
由上圖可看出：大量線程處於BLOCK狀態，分析具體線程dump文件，log4j大量阻塞
經過與框架組溝通，進行框架升級，初始化採用log4j2，複測結果如下：
由上圖線程快照圖，可以發現log4j阻塞已經消失。
繼續壓測
- 應用服務系統，CPU仍然壓不上去，當前最高消耗仍約60%，此時幾乎無線程阻塞現象，redis與數據庫均無明顯壓力。
- 抓數據庫快照分析：沒有鎖，獲取序列sql執行的時間也很快
- 監控redis資源使用情況：內存、IO、CPU 消耗情況均不高
後續分析思路
- 嘗試了使用JMeter工具壓單節點，每臺應用服務器cpu消耗可接近90%。
- 屏蔽F5，輪詢發四臺應用服務器，現象與經F5 一致。
- 使用JMeter壓單機，雙機，四機結果如下圖：
像是4臺app評分了2app的性能，質疑可能部署應用的物理機存在瓶頸。與系統環境組溝通後，排除了宿主機資源緊張的可能行。
分析梳理此交易後臺邏輯
使用jd-gui.exe反編譯項目組jar包,定位到獲取SQL如下：
抓取db2快照，找出此sql執行情況：
然後講項目中獲取序列的方法屏蔽（此處是寫了固定值）
修改前：
修改後：
再次進行復測：200線程壓測四臺應用，TPS約3000筆/秒，應用服務器CPU消耗均在90%，進而證實了取序列限制的了，系統的處理能力。
查詢數據庫序列配置，發現序列的cache值爲1，將此值改成經驗值200，進行壓測：
再次抓取數據庫快照（此時應用屏蔽的代碼已經還原）：
對比優化前後的數據庫快照圖：獲取序列的Total execution time 縮小非常明顯（總執行次數相差1w左右），如果經驗豐富的話，在最開始抓取數據庫快照便能看出獲取索引有問題，所以路還很長啊！
最後給大家留個思考題：系統重啓後，進行壓測ART趨勢圖去下,解釋下此現象。
