高可用場景下的限流測試及CPU資源消耗排查

測試場景：在高可用場景下進行限流測試。

被測交易：HTTP協(xié)議下的查詢類交易。

交易鏈路：jmeter - web - coimpre(前置服務(wù)) -- coimbp -- cobp（coimbp、coimpre均訪問同一數(shù)據(jù)庫）。

注：cobp位于合肥機房，其他服務(wù)位于北京機房，需注意跨網(wǎng)段網(wǎng)絡(luò)延遲可能導(dǎo)致TPS波動。

場景配置：配置coimpre服務(wù)的限流參數(shù)。

場景執(zhí)行：執(zhí)行場景使TPS大于限流參數(shù)，觸發(fā)限流報錯，通過日志和服務(wù)返回確認是否成功觸發(fā)限流。

測試問題：交易觸發(fā)限流后，監(jiān)控coimpre服務(wù)CPU資源，從5%上升至90%以上，兩次驗證執(zhí)行，確認問題存在。

排查思路：

1. 使用top命令監(jiān)控消耗CPU高的進程是否為java服務(wù)（程序為java開發(fā)）。

2. 使用top -Hp pid查看進程下的線程消耗，進一步確認是哪個線程消耗。

3. 打印線程dump文件，分析dump文件查看該線程此時的業(yè)務(wù)操作（第一個圖是Linux下jcmd生成的，第二個是使用Java VisualVM生成的）。

4. 定位問題，給出優(yōu)化意見，測試驗證。

4.1 通過dump文件分析，有問題的線程主要是在java net.URClassLoader.findResouce()方法，通過第一個圖可以看到j(luò)ava util.zip,ziprile getentry，結(jié)合兩個方法，并通過和開發(fā)溝通是否對某個ZIP文件中文件文件有操作。

4.2 項目組確認，交易報錯后，日志會打印錯誤信息并帶出是哪個jar包導(dǎo)致的錯誤，從而就會遍歷整個jar目錄。

4.3 共同認定是該問題導(dǎo)致的CPU升高，開發(fā)人員修改此處代碼，不再遍歷jar。

4.4 修改后，重新部署版本，再次驗證限流，CPU資源下降至10%。

• 2025年如意西游游戲攻略與技巧大全最新
• QQ飛車手游賽車數(shù)據(jù)大揭秘
• 云頂之弈s6（教你如何打造出完美的莎彌拉裝備）
• 《以陰陽師櫻之憶為例，詳解如何預(yù)約櫻之憶》（預(yù)約方法、注意事項、常見問題講解）
• 《洪荒文明俏羅成》技能玩法攻略秘籍（探索古老神話世界，成為文明創(chuàng)造者）