基于Dubbo的壓測調優執行個體

       不久前參與開發了一個基于dubbo分布式架構的底層賬單系統，并實作了其中的一部分業務接口，目前需對這些接口進行壓測，以評估生産環境所能承受的最大吞吐量。筆者以其中一個查詢接口為例來回顧此次壓測的整體流程

壓測準備：

1.調用查詢接口的測試jar包，作為dubbo-consumer，依賴了查詢服務的api，測試module基于maven開發，執行maven clean package即可通過編譯得到jar包

2.JMeter：

Apache組織開發的基于Java的壓力測試工具

方案：

無限次請求查詢接口（保證任意時刻并發量相同），觀察Error%為0，當請求平穩進行時的tps，為該接口吞吐量

實施：

1.JMeter中添加一個測試計劃，線程組容量分别設為10、20、50、80、100、200、400、1000、2000，通過jmeter csv data set config設定三組查詢參數

2.準備完畢後，依次在不同容量線程組下啟動測試計劃，結果如下

吞吐量折線統計圖

99%Line折線統計圖

Error%折現統計圖

       結論：當線程數為200時，tps達到1700+，随着線程數增加，99%Line明顯蹿升至6s，猜想部分線程請求不到資源，并且Error線程占比瞬間增多也印證了這一點。ps:如果同一組參數測試，壓測效果卻在遞減，可嘗試重新開機Jmeter。

思考&決策：

       目前測試結構中包含三個節點：本地測試Consumer節點—>查詢接口Provider節點—>資料庫節點，是以相鄰兩個節點間均可能産生并發瓶頸，是以需要定位具體問題發生的具體位置。由于壓測僅需一個節點，是以筆者使用了jVisualVM+jmx+jstacd組合，遠端監聽Dubbo服務所在的那台機器。

調優準備：

1.jstatd：（JDK自帶）基于RMI的服務程式，用于監控基于HotSpot的JVM中資源的建立及銷毀。首次使用需在被監控機器中加入權限授予檔案jstatd.all.policy（jdk的bin目錄下）

檔案内容：

grant codebase"file:${java.home}/../lib/tools.jar"{

permission java.security.AllPermission;

};

完畢後執行./jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=遠端伺服器ip &

對外預設開啟1099端口

2.jVisualVM：（JDK自帶）Java性能分析工具

3.jmx：（JDK自帶），是一個為應用程式、裝置、系統等植入管理功能的架構，如管理基于tomcat的web服務，本文中管理基于SpringBoot的Dubbo服務，需在啟動腳本中加入jmx的啟動配置

-Dcom.sun.management.jmxremote

-Djava.rmi.server.hostname=遠端伺服器ip

-Dcom.sun.management.jmxremote.port=18999（自定義）

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

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

方案&實施：

開啟壓測，并觀察jVisualVM中占用CPU時間非常多的熱點方法，并查詢遠端主機cpu使用率情況

jVisualVM觀察面闆

       發現在正常線程數請求時，擷取DriudDataSource連接配接池連接配接的方法CPU時間非常高，經查詢發現，系統中連接配接池的配置：initialSize、minIdle、maxActive都非常低，遂進行了

第一次調優：提升資料庫連接配接數

，連接配接池初始化連接配接數50，最小空閑連接配接數50，最高活躍連接配接數400。

       提升後，擷取連接配接方法的CPU時間明顯降低，遂測試線程數為400時的請求環境下的支援情況，發現已經開始出現error，即一部分線程請求不到資源，99%Line也達到6s之大！

分析：

       此時系統的資料庫連接配接池配置已經達到400，瓶頸不在此處，那麼會不會是遠端的資料庫節點存在瓶頸，于是遠端登入資料庫節點，發現mysql的允許連接配接數非常大，不存在瓶頸。既然請求線程數非常大，資料庫連接配接池連接配接數非常大，資料庫提供的連接配接數也足夠，CPU、JVM均沒有異常，那麼造成性能瓶頸的可能在與dubbo允許提供的連接配接線程數不足以比對壓測産生的線程數。

       定位到dubbo配置，發現并沒有顯式定義dubbo連接配接數，查閱dubbo開發文檔

dubbo預設連接配接線程數

       問題發現了：dubbo預設連接配接線程數為100，  而并發量400的請求線程對dubbo造成的壓力過大，導緻壓測不久就出現部分線程請求不到資源逾時的問題，遂進行了

第二次調優：提升Dubbo線程池連接配接數，

将連接配接數提升至1000。

        那麼是不是到此并發就不存在瓶頸了呢？1000請求線程+dubbo允許線程數1000+資料庫大連接配接數支援，理論上操作是沒有問題的，我們來實際跑一下，發現壓測時出現了更嚴重的問題，剛開始請求就出現了OOM及超過一半的error線程，準備去遠端機器列印一下執行日志，就連tail及ps指令都沒有可用資源供執行，停掉了請求線程，又費了九牛二虎之力停掉了服務程序，開始分析原因：各系統間通信均無瓶頸，問題會出在哪裡，是什麼原因撐爆了JVM，已知的條件是遠端服務至少有1000個線程在伺服器内生存，是不是線程量太大撐爆了機器？由于JVM中，棧空間線程私有，查閱JVM參數

JVM線程棧空間

伺服器為linux系統，那預設ThreadStackSize=1024K，那麼1000個線程JVM就需要建立1000*1024k即1個G的空間！這個節點部署三個服務，光一個服務的請求線程就占據1個G，記憶體溢出也是情理之中的了，遂進行了

第三次調優：減少線程棧空間

，ThreadStackSize調至256K，也是夠用的，再次模拟1000線程并發，OK，無論是系統間線程調用還是記憶體中JVM空間都在正常情況下，并未出現線程請求不到資源的情況。

總結：

       本次壓測主要目的是确定單節點在生産環境所能承受的tps峰值，并借助測試資料反向分析之前開發及單元測試無法覆寫的隐藏問題，通過三次調優，我們可以發現，該環境下瓶頸主要在系統間請求發生時，以及JVM自身無法負載大資料量線程導緻。當然也有可能發生在程式本身過程中，如邏輯中創造大量對象，消耗大量記憶體，或同步邏輯處理塊設計欠缺，導緻死鎖、線程餓死等。筆者所描述的問題隻是衆多壓測問題中的一小部分，分析、操作難免有疏漏，歡迎各位同學予以指正及建議。感謝華哥、林哥指導，感謝一鳴同學協助~