arthas火焰图async-profiler在云交易中的运用
在日常工作中经常会遇到系统应用出现full gc、cpu内存飙高等场景,如果想要快速解决这些线上问题就需要首先能快速定位,最好能定位到具体代码。本文旨在通过一款线上监控诊断产品,阿里巴巴的arthas(阿尔萨斯)内部集成的火焰图工具async-profiler结合自身系统应用中的使用,方便我们能够快速定位线上问题。
一、背景
1、在订单域任务系统,master机器和slaver机器频繁出现full gc和cpu间歇性升高的现象,young GC也出现平均1分钟10次。master机器线程也增加到1500左右。系统应用采用的是CMS垃圾回收器,4c8g分配堆内存大小4G。但是堆内存和非堆内存正常。
2、随着时间推移,full gc从每隔20分钟一次变成 每个5分钟或者3分钟一次,stop the world。FULL GC 和 Young GC 不正常,如下图。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-1737jEhOOY0ZuopdyX.png)
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-18NuUpGvg9ridPojg.png)
堆内存和非堆内存正常。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-20QB7j0VlE6d7mabW.png)
CPU一分钟一次达到高点,部分机器达到75%以上。线程,在上午超过1400,重启后正常。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-2121S82d7QJNQWEFmb.png)
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-228rK9lHbbEywVTfg.png)
系统稳定性受到挑战,需要尽快排查出问题所在。
二、工具选型及实践
市面上很多排查工具,怎样才能快速排查出问题。结合arthas、async-profiler火焰图(采样)、visualVM(跨时间dump文件对比)、gceasy这四种工具,都进行实战对比。
1、arthas分析
下图分析master机器是反序列化商品域渠道配置接口对象耗CPU
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-377cvdsZv7ZqrlQUm.png)
下图也发现反查快手任务也会引起高cpu。分析这台机器既是master,又是slaver。slaver会执行反查快手任务。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-41zVuIba8PnezBeXX.png)
2、visualVM分析
dump两个文件,跨时一天,进行对比。
启动visualVM
cd /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/bin
jvisualvm
/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/visualvm目录下 visualvm.conf修改内存空间大小
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-43GSPpRlZ6y9otFpp.png)
对比发现,最大是查询ES的数据,反序列化对象并不是最大,但是也能在dump文件中查找到。因为arthas查的是CPU和线程,dump文件是内存,所以不完全一致。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-44P8YbrCZI0vh22XB.png)
一次500个
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-4517aitDMX0QuZaOY0.png)
3、gceasy分析
修改jvm,-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:./gc.log,打印gc日志。
通过gceasy.io线上对比工具,没有内存泄露,但是也未发现gc产生的具体原因。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-46qNj0K0a46dB8wrCI.png)
4、async-profiler火焰图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-47ipfDnoGfTU9tVm7.png)
从上图,看到主要分为两大部分,左边的反查快手任务(因master机器,既是master,也是slaver),右边是扫描es里面代扣任务的反序列化对象占用很大比重。和arthas分析的一样。
下载内存火焰图,可以看到左边也是快手反查,右边则是查询ES(包含反序列化对象)。和dump文件比较能核对上。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-52YptFILcoEr52FpQR.png)
三、修复上线
根据上述四种工具的排查过程,可以明显看到使用arthas集成的async-profiler更直观和方便,便于定位问题。在修改对应的代码后,上线进行后续观察系统稳定正常。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-17-59xP0DO7KN17nc6bhy.png)
四、使用步骤
async-profiler 火焰图。
1、申请堡垒机(root权限)
2、登陆以后下载 最新的jar包 wget https://alibaba.github.io/arthas/arthas-boot.jar
3、安装(admin权限 cd)java -jar arthas-boot.jar
4、查看cpu耗时、dashboard(q命令表示退出)、thread
5、profiler start 启动火焰图工具进行采样
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-18-03KjOg17VM7IiQvssa.png)
https://jlynet.github.io/2021/08/07/Java%E8%AF%8A%E6%96%AD%E5%B7%A5%E5%85%B7Arthas%E9%AB%98%E7%BA%A7%E5%91%BD%E4%BB%A4%E6%95%99%E7%A8%8B/Arthasprofiler%E5%91%BD%E4%BB%A4/
profiler getSamples
profiler status
profiler stop --format html。生成火焰图
6、下载火焰图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-18-04pCYiBn6pqt2UYx46.png)
7、多种维度:
lock 锁对象\alloc 内存\默认cpu
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-18-05j37u6f23VZLC17UiI.png)
8、效果
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-18-06Yjj6l6Tf23urBFG.png)
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-18-06NtkIsSHtcG6jGb6.png)
CPU\内存等不同的火焰图
9、其他
还可以反编译jar包的代码
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-18-10SURhlmE0vGJh19Hx.png)
统计方法调用时间
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-02-17-18-11gjHFsw69ThAl2Od.png)
以上。本文旨在通过具体的场景运用和实操,介绍arthas火焰图如何在系统中快速定位问题,欢迎感兴趣的同事一起学习探讨。
五、参考资料
https://gceasy.io/diamondgc-report.jsp?oTxnId_value=e8692cc6-f79d-467c-8e90-6aa96f1b429d
https://blog.csdn.net/lkx444368875/article/details/104906673
https://blog.csdn.net/CoderBruis/article/details/101234738