測試場景：高可用場景--限流測試； 被測交易：查詢類交易，HTTP協(xié)議； 交易鏈路：jmeter - web - coimpre(前置服務) -- coimbp -- cobp （coimbp 、coimpre 都會訪問同一個數據庫）； 注：cobp 為合肥機房，其他服務均為北京機房，要注意跨網段存
測試場景：在高可用場景下進行限流測試。
被測交易：HTTP協(xié)議下的查詢類交易。
交易鏈路：jmeter - web - coimpre(前置服務) -- coimbp -- cobp（coimbp、coimpre均訪問同一數據庫）。
注：cobp位于合肥機房，其他服務位于北京機房，需注意跨網段網絡延遲可能導致TPS波動。
場景配置：配置coimpre服務的限流參數。
場景執(zhí)行：執(zhí)行場景使TPS大于限流參數，觸發(fā)限流報錯，通過日志和服務返回確認是否成功觸發(fā)限流。
測試問題：交易觸發(fā)限流后，監(jiān)控coimpre服務CPU資源，從5%上升至90%以上，兩次驗證執(zhí)行，確認問題存在。
排查思路：
1. 使用top命令監(jiān)控消耗CPU高的進程是否為java服務（程序為java開發(fā)）。
2. 使用top -Hp pid查看進程下的線程消耗，進一步確認是哪個線程消耗。
3. 打印線程dump文件，分析dump文件查看該線程此時的業(yè)務操作（第一個圖是Linux下jcmd生成的，第二個是使用Java VisualVM生成的）。
4. 定位問題，給出優(yōu)化意見，測試驗證。
4.1 通過dump文件分析，有問題的線程主要是在java net.URClassLoader.findResouce()方法，通過第一個圖可以看到java util.zip,ziprile getentry，結合兩個方法，并通過和開發(fā)溝通是否對某個ZIP文件中文件文件有操作。
4.2 項目組確認，交易報錯后，日志會打印錯誤信息并帶出是哪個jar包導致的錯誤，從而就會遍歷整個jar目錄。
4.3 共同認定是該問題導致的CPU升高，開發(fā)人員修改此處代碼，不再遍歷jar。
4.4 修改后，重新部署版本，再次驗證限流，CPU資源下降至10%。
小編推薦閱讀
