性能瓶颈定位更快更准:ARMS 持续剖析能力升级解析
作者:铖朴、穆司
持续剖析介绍
随着软件技术发展迭代,很多企业软件系统也逐步从单体应用向云原生微服务架构演进,一方面让应用实现高并发、易扩展、高开发敏捷度等效果,但此外也让软件应用链路变得越来越长,依赖的各种外部技术越来越多,一些线上问题排查起来变得困难重重。
尽管经过过去十几年的发展,分布式系统与之对应的可观测技术快速演进,在一定程度上解决了很多问题,但有一些问题定位起来仍然很吃力,如下图是几个非常有代表性的线上常见问题:
持续性能剖析技术是一种通过采集应用相关线程在申请相关资源时的方法栈状态信息,再通过火焰图等可视化技术绘制出对应资源使用分布情况,最后,确定相关时段特定资源波动根因的一种强有力技术。
开箱即用的持续剖析能力
阿里云应用可观测产品 - 应用实时监控服务 ARMS 早在 2022 年就上线了持续剖析产品能力,帮助用户定位常见的性能方面疑难问题:
具体而言,其主要包含以下 3 块核心功能:
代码热点【1】:其通过墙钟热点关联 Trace 信息,可帮助用户定位:
- 当业务太复杂,偶发性慢调用无法复现时,代码热点可为您还原代码真实方法层面的执行轨迹。
- 当调用链中因为缺失对应用代码非框架层面的方法埋点时,代码热点帮您还原对应缺失埋点的实际方法调用耗时。
CPU 热点【2】:通过定时采集正在执行 CPU 线程的方法栈快照,帮助用户定位:
- 当系统 CPU 使用率较高时,帮助您快速定位导致 CPU 消耗高的相关业务逻辑方法栈。
内存热点【3】:通过记录线程每次触发堆内存分配阈值时的内存分配大小/次数,及对应方法栈快照,帮助用户定位:
- 当系统 JVM 堆内存利用率高时,帮助您快速定位导致堆内存申请量/申请次数高的相关业务逻辑方法栈。
经过过去几年的大量客户使用和持续演进优化,近期,我们在产品功能易用性上进行了一系列升级,本文接下来对其中重要升级进行一一介绍。
优化存储计算引擎:让数据检索如丝般流畅高效
火焰图数据结构复杂,无论是大数据量的存储还是聚合计算都存在不小的挑战,因此,业界一些产品的常见做法是仅支持临时开启功能采集一段时间数据以及较短时间间隔的数据聚合分析,虽然使用过程略显繁琐,但在一定程度上可以实现辅助排查一般性能瓶颈问题,当遇到一些不易复现的场景问题时,问题定位成本就会非常的高!
本次产品升级后,我们在数据格式和查询引擎方面都做了大量优化,持续剖析查询时间间隔和对象从之前的仅支持 1/5/15 分钟数据聚合效果到现在的天级别、多实例、多线程等维度的秒级聚合,让用户聚合范围不仅广还更细,更好地定位各种性能问题。
AI Copilot 驱动火焰图分析:一键洞察性能热点
过去我们从用户侧了解的情况来看,虽然火焰图工具对于排查性能问题非常有效,但是火焰图的阅读对大量客户都存在较大阻碍。因此,我们最新版持续剖析支持基于 AI Copilot 分析火焰图,让不懂火焰图阅读的用户,也能低成本地洞察火焰图中的性能瓶颈。
效果演示
- 应用开启持续剖析后,在控制台选择对应应用,以 CPU 热点问题举例,在下图所示的火焰图页面中,点击火焰图右上角的 AI Copilot 分析紫色魔法棒触发进行分析:
- 针对上述火焰图,Copilot 快速给出了分析报告和建议:
- 从报告结果中可见,java.util.LinkedList.node(int) 方法在火焰图中拥有较长的耗时,CPU 占比较大:
- 除了分析和建议,用户还可以提供部分隐匿关键信息的代码片段,让模型结合上下文,给出有针对性的代码优化建议。
- 在应用完成代码调整优化后,还可以基于持续剖析能力生成的火焰图回归验证优化结果。
差分火焰图:精准对比性能差异
差分火焰图通过对比两段时间内的性能数据,生成差分火焰图(红色表示性能下降,蓝色表示性能提升),找出不同时段性能显著变化的函数。其对应用性能在一段时间前后有差异变化的场景定位非常有帮助。在新版持续性能剖析中,提供了开箱即用的差分火焰图分析能力。
效果演示
- 应用开启持续剖析后,在控制台选择对应应用,例如CPU热点问题定位为例,点击页面左上角的"数据对比"按钮生成前后两段时间的查分火焰图:
- 根据生成的差分火焰图,可以基于使用 AI Copilot 分析火焰图查看不同时段的差分热点:
小结
除了以上能力更新以外,更多能力和细节,请参考功能升级公告【4】和产品文档【5】,如果您对文中提到的 ARMS 中的持续剖析功能感兴趣,欢迎扫描下方二维码,加入钉钉群(22560019672)聊讨论和反馈建议!
【1】代码热点
【2】CPU热点
【3】内存热点
【4】功能升级公告
【5】产品文档
https://help.aliyun.com/zh/arms/application-monitoring/user-guide/continuous-profiling/

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
比 Cursor 更快更稳定的 Coding Agent?
搞了 2 年直播,我也是搞出名堂来了。 张宏波说要来我们这里搞直播,聊一聊 Coding Agent。 张宏波是谁? 他是编程语言领域的专家,是 OCaml 语言的前核心开发人员,OCaml 编译器获得过 2023 年 ACM SIGPLAN 编程语言软件奖。 此外,他还创造了编程语言ReScript,被Meta、谷歌、育碧、TinyMCE 等多个公司商用。 就这成就,已经值得吹一辈子了吧? 但张宏波不一样,他觉得很遗憾。 因为 ReScript 具备相当的技术实力,并且远超一些同行,但是相较于微软的 TypeScript 或者谷歌的 Dart,ReScript 的影响力远没有达到它应有的高度。 他想要打造的,是一款现象级的编程语言。 一直以来,张宏波都不甘平庸。就连他当初考到清华大学电气工程及自动化系,都说是因为高考发挥失常才被调剂过去的。他真正想进的,是他一年后成功转入的清华电子系。 所以在 2022 年,张宏波结束了他在 Meta 的 5 年职业生涯,来到了粤港澳大湾区数字经济研究院(IDEA 研究院)组建了基础软件中心,从零开始创立了 MoonBit。 这里插一句,张宏波加入 ...
- 下一篇
不增加 GPU,首 Token 延迟下降 50%|LLM 服务负载均衡的新实践
作者:钰诚 简介 传统的负载均衡算法主要设计用于通用的 Web 服务或微服务架构中,其目标是通过最小化响应时间、最大化吞吐量或保持服务器负载平衡来提高系统的整体效率,常见的负载均衡算法有轮询、随机、最小请求数、一致性哈希等。然而,在面对 LLM 服务时,这些传统方法往往暴露出以下几个关键缺陷: 忽略任务复杂度差异:LLM 推理请求的复杂度差异极大。例如,一个长文本生成任务可能需要数十倍于短文本分类任务的计算资源。而传统负载均衡器无法感知这种差异,容易导致某些节点过载,而其他节点空闲,造成资源浪费和响应延迟。 缺乏对 GPU 资源水位的感知:在 LLM 推理服务中,计算瓶颈主要集中在 GPU 上,传统负载均衡器往往无法感知到这一细粒度的资源消耗情况,导致某些 GPU 节点因显存不足而拒绝请求或响应缓慢,而其他节点却处于空闲状态。 缺乏对 KV Cache 的复用能力:在并发请求处理中,如果多个请求具有相似的前缀,则它们的 KV Cache 可能存在重叠部分,可以通过共享或压缩的方式减少显存占用并提升生成速度。传统负载均衡策略并未考虑请求之间的语义相似性或 KV Cache 的可复用性,难...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS关闭SELinux安全模块
- Docker安装Oracle12C,快速搭建Oracle学习环境
- MySQL8.0.19开启GTID主从同步CentOS8
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7设置SWAP分区,小内存服务器的救世主
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Linux系统CentOS6、CentOS7手动修改IP地址