转载

2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题

业务上一个新业务上线,发现CPU使用率较高,我们的业务特点一般是IO密集型,所以一般呈现CPU使用率较低,但是QPS较高的特点,所以对这个特殊的服务进行性能分析,以下是分析过程。

网络性能分析

  • 新应用上线,发现CPU较高,如图所示
    2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题
  • 从cpu使用率的细节发现%si中断使用率集中在cpu0上,查看中断类型
    2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题
  • 发现硬中断的处理集中在CPU0上,推断网卡不支持多队列特性
    2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题
  • 果然推断正确,然后决定找两台网卡支持多队列的机器对比性能
    2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题
  • 从监控中可以看到,两种机型在P999的接口响应延迟上相差一倍
    2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题

CPU使用率还没分析

跑题了,前面分析CPU的过程中无意间发现了中断不平均的问题,但并不是我们CPU使用率高的原因,CPU主要还是%us高,回来分析CPU使用率,由于代码不是本人所写,不会直接去分析代码,那样无异于大海捞针,拿出珍藏的perf大法,生成火焰图分析。

CPU火焰图的生成方法参考前面的文章:

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

生成的火焰图如下:

oss.zrbcool.top/picgo/ad-da…
2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题

瓶颈点1

CoohuaAnalytics$KafkaConsumer:::send方法中Gzip压缩占比较高

已经定位到方法级别,再看代码就快速很多,直接找到具体位置,找到第一个消耗大户:Gzip压缩

2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题

瓶颈点2

展开2这个波峰,查看到这个getOurStackTrace方法占用了大比例的CPU,怀疑代码里面频繁用丢异常的方式获取当前代码栈

2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题

直接看代码

2019-07-24 实战火焰图分析CPU使用率解决JAVA应用线上性能问题
果然如推断,找到第二个CPU消耗大户:new Exception().getStackTrace()

定位到具体的代码,可以看到对每个请求的参数进行了gzip解压缩

原文  https://juejin.im/post/5d3a6e26f265da1b6c5fbb8a
正文到此结束
Loading...