最近壓測一項目，遇到的性能問題比較典型，過程記錄下來，給大家做定位調優參考；
表象：
單接口負載測試，qps最高到300，響應時間200ms，應用cpu達到90%以上，8c機器，如下圖，寫到這裡可能有部分同學就想說：處理能力還可以，不行就加機器,擴節點！
當然這是一種解決方案，但我認為如果直接這麼去做，這是一種最low的方案，而且並不能發現本質問題；回到剛剛說的，我僅僅描述了應用服務器的狀態，從完整的性能測試來看，整個鏈路各個指標都需要監控，把鏈路擼了一遍之後，應用到數據層流量也是較大的如下圖（請不要說擴帶寬）
從監控中發現了這兩個問題，繼續看應用cpu，查看部署細節，該服務器部署了約10個docker節點，查看各個docker節點狀態，其中一臺達到623.59%（*核數）如圖，
找到排查重點，進入相關容器，jstat查看gc狀態，ygc可以達到1s三次，也是可以的，剛剛還說了啥，流量，Iftop後發現主要集中在應用跟redis服務器交互，從上面描述看，我們可以總結應用獲取到redis大量的數據，導致流量較高，且大量數據會頻繁的ygc會導致應用cpu的飆升，這麼解釋沒毛病，道理上是通的，但這只是你的猜測，還要去做進一步驗證，說了大量數據，那是什麼業務的數據，在不做代碼走讀的情況下，我一般就dump，獲取cpu消耗熱點方法，dump到文件中發現用戶信息中帶大量優惠券的jedis方法（如圖），
ok，到了這一步問題基本就已經很明朗了，跟開發確認後，確實業務層面獲取了大量無效優惠券信息導致，開發進行業務層過濾後，qps達到1500，網絡，cpu迴歸正常。
分享到:
閱讀更多 測試開發圈子 的文章
