本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议 》和 《 阿里云开发者社区知识产权保护指引 》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单 进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

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

网络性能分析

新应用上线，发现CPU较高，如图所示

从cpu使用率的细节发现%si中断使用率集中在cpu0上，查看中断类型

发现硬中断的处理集中在CPU0上，推断网卡不支持多队列特性

果然推断正确，然后决定找两台网卡支持多队列的机器对比性能

从监控中可以看到，两种机型在P999的接口响应延迟上相差一倍

CPU使用率还没分析

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

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

使用FlameGraph分析JAVA应用性能

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

生成的火焰图如下：
http://oss.zrbcool.top/picgo/ad-data-web03.svg

CoohuaAnalytics$KafkaConsumer:::send方法中Gzip压缩占比较高
已经定位到方法级别，再看代码就快速很多，直接找到具体位置，找到第一个消耗大户：Gzip压缩

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

直接看代码

果然如推断，找到第二个CPU消耗大户：new Exception().getStackTrace()

展开波峰3，可以看到是这个Gzip解压缩

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

到此我们就找到了这个应用的三个主要的CPU消耗点，通过火焰图，我们很方便的可以分析到具体代码级别的CPU使用情况，完全可以将应用当做一个黑盒来分析，分析性能之前，我对代码完全不了解的情况下分析到了CPU使用率的性能瓶颈。

后续： 等过几天优化完成后再行对比CPU使用率情况。

AIGC初体验：部署Stable Diffusion玩转AI绘画（CPU版） 使用Java面向对象编写网络通信程序应用 Elasticsearch Java API Client 开发 手动部署Java Web环境（Alibaba Cloud Linux 2） 搭建Java Web开发环境（Anolis OS）