2019-07-24 實戰火焰圖分析CPU使用率解決JAVA應用線上性能問題

開源項目推薦

Pepper Metrics是我與同事開發的一個開源工具(github.com/zrbcool/pep…)，其經過收集jedis/mybatis/httpservlet/dubbo/motan的運行性能統計，並暴露成prometheus等主流時序數據庫兼容數據，經過grafana展現趨勢。其插件化的架構也很是方便使用者擴展並集成其餘開源組件。
請你們給個star，同時歡迎你們成爲開發者提交PR一塊兒完善項目。

背景

業務上一個新業務上線，發現CPU使用率較高，咱們的業務特色通常是IO密集型，因此通常呈現CPU使用率較低，可是QPS較高的特色，因此對這個特殊的服務進行性能分析，如下是分析過程。

網絡性能分析

• 新應用上線，發現CPU較高，如圖所示
  

  

• 從cpu使用率的細節發現%si中斷使用率集中在cpu0上，查看中斷類型
  

  

• 發現硬中斷的處理集中在CPU0上，推斷網卡不支持多隊列特性

  

• 果真推斷正確，而後決定找兩臺網卡支持多隊列的機器對比性能
  

  

• 從監控中能夠看到，兩種機型在P999的接口響應延遲上相差一倍
  

  

CPU使用率還沒分析

跑題了，前面分析CPU的過程當中無心間發現了中斷不平均的問題，但並非咱們CPU使用率高的緣由，CPU主要仍是%us高，回來分析CPU使用率，因爲代碼不是本人所寫，不會直接去分析代碼，那樣無異於大海撈針，拿出珍藏的perf大法，生成火焰圖分析。

CPU火焰圖的生成方法參考前面的文章：

• 使用FlameGraph分析JAVA應用性能
• Docker中使用FlameGraph分析JVM應用性能

生成的火焰圖以下：
oss.zrbcool.top/picgo/ad-da…

瓶頸點1

CoohuaAnalytics$KafkaConsumer:::send方法中Gzip壓縮佔比較高
已經定位到方法級別，再看代碼就快速不少，直接找到具體位置，找到第一個消耗大戶：Gzip壓縮

瓶頸點2

展開2這個波峯，查看到這個getOurStackTrace方法佔用了大比例的CPU，懷疑代碼裏面頻繁用丟異常的方式獲取當前代碼棧

直接看代碼

果真如推斷，找到第二個CPU消耗大戶：new Exception().getStackTrace()

瓶頸點3

展開波峯3，能夠看到是這個Gzip解壓縮

定位到具體的代碼，能夠看到對每一個請求的參數進行了gzip解壓縮

總結

到此咱們就找到了這個應用的三個主要的CPU消耗點，經過火焰圖，咱們很方便的能夠分析到具體代碼級別的CPU使用狀況，徹底能夠將應用當作一個黑盒來分析，分析性能以前，我對代碼徹底不瞭解的狀況下分析到了CPU使用率的性能瓶頸。

後續： 等過幾天優化完成後再行對比CPU使用率狀況。