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使用率状况。