全屏类网站建设,人力资源公司如何做推广,企业网站做的好,域名注册查询系统本文主要分享火焰图使用技巧#xff0c;介绍 systemtap 的原理机制#xff0c;如何使用火焰图快速定位性能问题原因#xff0c;同时加深对 systemtap 的理解。让我们回想一下#xff0c;曾经作为编程新手的我们是如何调优程序的#xff1f;通常是在没有数据的情况下依靠主…本文主要分享火焰图使用技巧介绍 systemtap 的原理机制如何使用火焰图快速定位性能问题原因同时加深对 systemtap 的理解。让我们回想一下曾经作为编程新手的我们是如何调优程序的通常是在没有数据的情况下依靠主观臆断来瞎蒙稍微有些经验的同学则会对差异代码进行二分或者逐段调试。这种定位问题的方式不仅耗时耗力而且还不具有通用性当遇到其他类似的性能问题时需要重复踩坑、填坑那么如何避免这种情况呢俗语有曰兵欲善其事必先利其器个人认为程序员定位性能问题也需要一件“利器”。 如同医生给病人看病需要依靠专业的医学工具比如 X 光片、听诊器等进行诊断最后依据医学工具的检验结果快速精准的定位出病因所在。性能调优工具比如 perf / gprof 等之于性能调优就像 X 光之于病人一样它可以一针见血的指出程序的性能瓶颈。但是常用的性能调优工具 perf 等在呈现内容上只能单一的列出调用栈或者非层次化的时间分布不够直观。这里我推荐大家配合使用火焰图它将 perf 等工具采集的数据呈现得更为直观。初识火焰图火焰图Flame Graph是由 Linux 性能优化大师 Brendan Gregg 发明的和所有其他的 profiling 方法不同的是火焰图以一个全局的视野来看待时间分布它从底部往顶部列出所有可能导致性能瓶颈的调用栈。火焰图整个图形看起来就像一个跳动的火焰这就是它名字的由来。火焰图有以下特征这里以 on-cpu 火焰图为例每一列代表一个调用栈每一个格子代表一个函数纵轴展示了栈的深度按照调用关系从下到上排列。最顶上格子代表采样时正在占用 cpu 的函数。横轴的意义是指火焰图将采集的多个调用栈信息通过按字母横向排序的方式将众多信息聚合在一起。需要注意的是它并不代表时间。横轴格子的宽度代表其在采样中出现频率所以一个格子的宽度越大说明它是瓶颈原因的可能性就越大。火焰图格子的颜色是随机的暖色调方便区分各个调用信息。其他的采样方式也可以使用火焰图 on-cpu 火焰图横轴是指 cpu 占用时间off-cpu 火焰图横轴则代表阻塞时间。采样可以是单线程、多线程、多进程甚至是多 host进阶用法可以参考附录进阶阅读火焰图类型常见的火焰图类型有 On-CPUOff-CPU还有 MemoryHot/ColdDifferential 等等。他们分别适合处理什么样的问题呢这里笔者主要使用到的是 On-CPU、Off-CPU 以及 Memory 火焰图所以这里仅仅对这三种火焰图作比较也欢迎大家补充和斧正。火焰图类型横轴含义纵轴含义解决问题采样方式cpu 火焰图cpu占用时间调用栈找出 cpu 占用高的问题函数分析代码热路径固定频率采样 cpu 调用栈off-cpu 火焰图阻塞时间调用栈i/o、网络等阻塞场景导致的性能下降锁竞争、死锁导致的性能下降问题固定频率采样 阻塞事件调用栈内存火焰图内存申请/释放函数调用次数调用栈内存泄露问题内存占用高的对象/申请内存多的函数虚拟内存或物理内存泄露问题有四种方式 跟踪malloc/free跟踪brk跟踪mmap跟踪页错误Hot/Cold 火焰图on-CPU 火焰图和 off-CPU 火焰图结合在一起综合展示调用栈需要结合 cpu 占用以及阻塞分析的场景off-CPU 火焰图无法直观判断问题的场景on-CPU 火焰图和 off-CPU 火焰图结合火焰图分析技巧纵轴代表调用栈的深度栈桢数用于表示函数间调用关系下面的函数是上面函数的父函数。横轴代表调用频次一个格子的宽度越大越说明其可能是瓶颈原因。不同类型火焰图适合优化的场景不同比如 on-cpu 火焰图适合分析 cpu 占用高的问题函数off-cpu 火焰图适合解决阻塞和锁抢占问题。无意义的事情横向先后顺序是为了聚合跟函数间依赖或调用关系无关火焰图各种颜色是为方便区分本身不具有特殊含义多练习进行性能优化有意识的使用火焰图的方式进行性能调优如果时间充裕如何绘制火焰图要生成火焰图必须要有一个顺手的动态追踪工具如果操作系统是 Linux 的话那么通常通常是 perf 或者 systemtap 中的一种。其中 perf 相对更常用多数 Linux 都包含了 perf 这个工具可以直接使用SystemTap 则功能更为强大监控也更为灵活。网上关于如何使用 perf 绘制火焰图的文章非常多而且丰富所以本文将以 SystemTap 为例。SystemTap 是动态追踪工具它通过探针机制来采集内核或者应用程序的运行信息从而可以不用修改内核和应用程序的代码就获得丰富的信息帮你分析、定位想要排查的问题。SystemTap 定义了一种类似的 DSL 脚本语言方便用户根据需要自由扩展。不过不同于动态追踪的鼻祖 DTrace SystemTap 并没有常驻内核的运行时它需要先把脚本编译为内核模块然后再插入到内核中执行。这也导致 SystemTap 启动比较缓慢并且依赖于完整的调试符号表。使用 SystemTap 绘制火焰图的主要流程如下安装 SystemTap 以及 操作系统符号调试表根据自己所需绘制的火焰图类型以及进程类型选择合适的脚本生成内核模块运行 SystemTap 或者运行生成的内核模块统计数据将统计数据转换成火焰图本文演示步骤将会基于操作系统 Tlinux 2.2安装 SystemTap 以及 操作系统符号调试表使用 yum 工具安装 systemtap:yum install systemtap systemtap-runtime由于 systemtap 工具依赖于完整的调试符号表而且生产环境不同机器的内核版本不同虽然都是Tlinux 2.2版本但是内核版本后面的小版本不一样可以通过 uname -a 命令查看所以我们还需要安装 kernel-debuginfo 包、 kernel-devel 包 我这里是安装了这两个依赖包kernel-devel-3.10.107-1-tlinux2-0046.x86_64
kernel-debuginfo-3.10.107-1-tlinux2-0046.x86_64根据自己所需绘制的火焰图类型以及进程类型选择合适的脚本使用 SystemTap 统计相关数据往往需要自己依照它的语法编写脚本具有一定门槛。幸运的是github 上春哥agentzh开源了两组他常用的 SystemTap 脚本openresty-systemtap-toolkit 和 stapxx这两个工具集能够覆盖大部分 C 进程、nginx 进程以及 Openresty 进程的性能问题场景。我们这里需要绘制 off-cpu 火焰图所以使用 sample-bt-off-cpu 脚本即可生成内核模块现在我们有了统计脚本也安装好了 systemtap正常来说就可以使用了但由于 systemtap 是通过生成内核模块的方式统计相关探针的统计数据而 tlinux 要求所有运行的内核模块需要先到 tlinux 平台签名才可以运行所以故需要先修改 off-cpu 脚本让其先生成内核模块之后对该内核模块作签名最后使用 systemtap 命令手工运行该脚本统计监控数据Systemtap 执行流程如下parse分析脚本语法elaborate展开脚本 中定义的探针和连接预定义脚本库分析内核和内核模块的调试信息translate.将脚本编译成c语言内核模块文件放 在$HOME/xxx.c 缓存起来避免同一脚本多次编译build将c语言模块文件编译成.ko的内核模块也缓存起来。把模块交给staprunstaprun加载内核模块到内核空间,stapio连接内核模块和用户空间提供交互IO通道,采集数据。所以我们这里修改下 off-cpu 的 stap 脚本让其只运行完第四阶段只生成一个内核模块// 在 stap 命令后增加 -p4 参数告诉systemtap当前只需要执行到第四阶段
open my $in, |stap -p4 --skip-badvars --all-modules -x $pid -d $exec_path --ldd $d_so_args $stap_args -
or die Cannot run stap: $!n;修改好之后运行脚本会生成一个内核模块// -p 8682 是需要监控的进程的进程号
// -t 30 是指会采样30秒
./sample-bt-off-cpu -p 8692 -t 30生成的内核模块名称形如 stap_xxxxx.ko模块名称 由于读者并不需要关心内核模块签名故章节略过运行内核模块统计数据内核模块签名完成后便可以使用 staprun 命令手工运行相关内核模块了命令// 注意签名脚本会将生产的内核模块重命名需要将名字改回去……脚本bug
staprun -x {进程号} {内核模块名} demo.bt值得注意的是监控的进程要有一定负载 systemtap 才可以采集到相关数据即在采集时同时需要要有一定请求量通常是自己构造请求压测进程将统计数据转换成火焰图获得了统计数据 demo.bt 后便可以使用火焰图工具绘制火焰图了下载 FlameGraph链接https://github.com/brendangregg/FlameGraph命令./stackcollapse-stap.pl demo.bt demo.folded
./flamegraph.pl demo.folded demo.svg这样便获得了 off-cpu 火焰图看图说话趁热打铁通过几张火焰图熟悉下如何使用火焰图图片来自于春哥微博或者个人近期定位的问题on-cpu 火焰图Apache APISIX QPS急剧下降问题Apache APISIX 是一个开源国产的高性能 API 网关之前在进行选型压测时发现当 Route 匹配不中场景下 QPS 急剧下降在其 CPU 四十八核占用率几乎达到100%的情况下只有几千 QPS通过绘制火焰图发现其主要耗时在一个 table 插入阶段(lj_cf_table_insert)分析代码发现是该 table 一直没有释放每次匹配不中路由会插入数据导致表越来越大后续插入耗时过长导致 QPS 下降。off-cpu 火焰图nginx 互斥锁问题这是一张 nginx 的 off-cpu 火焰图我们可以很快锁定到 ngx_common_set_cache_fs_size - ngx_shmtx_lock - sem_wait 这段逻辑使用到了互斥锁它让 nginx 进程绝大部分阻塞等待时间花费在获取该锁。agent 监控上报断点问题这是一张 agent 的 off-cpu 火焰图它是一个多线程异步事件模型主线程处理各个消息多个线程分别负责配置下发或者监控上报的职责。当前问题出现在监控上报性能差无法在周期一分钟内完成监控数据上报导致监控断点通过 off-cpu 火焰图我们可以分析出该上报线程花费了大量的时间使用 curl_easy_perform 接口收发 http 监控数据消息中。依据火焰图将发送 http 消息的逻辑改为异步非阻塞后该问题解决。附录进阶阅读谷歌搜索演讲Blazing Performance with Flame Graphs演讲 ppthttps://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs《SystemTap新手指南》https://spacewander.gitbooks.io/systemtapbeginnersguide_zh/content/index.htmlFAQ使用 perf 或者 systemtap 的方式采集数据会对后台服务有性能影响吗有但是很小可以基本忽略不计。它们使用系统的探针或者使用一些自定义的动态探针进行数据采集第一对代码无侵入性它既不需要停止服务也不需要修改应用程序的代码第二它们是以内核模块/内核原生的方式跟踪用户态和内核态的所有事件并通过一系列优化措施进行采样统计对目标服务性能影响极小大概在5%左右或者更低的性能损耗。相较于将进程运行在沙箱的 valgrind 工具或静态调试工具 gdb 来说动态追踪 perf 或者 systemtap 或者 ebpf 的性能损耗基本可以忽略不计。目标进程重启后systemtap 是否需要重新生成内核模块不需要。甚至同一个 linux 内核版本下的同一个二进制进程md5值一致在安装 kernel 调试符号表后便可以在生成采集指标的内核模块并且可以多次使用。当 linux 内核版本不一致符号表有变化需要重新生成内核模块当目标进程二进制文件重新编译后也需要重新生成统计用的 systemtap 内核模块。作者yousali(厉辉)腾讯 CSIG 后台开发工程师更多干货尽在腾讯技术官方QQ交流群已建立交流讨论可加957411539。
