转载

白话火焰图

很多人感冒发烧的时候,往往会模仿神农氏尝百草的路子:先尝尝抗病毒的药,再试试抗细菌的药,甭管家里有什么药挨个试,什么中药西药,瞎猫总会碰上死耗子,如此做法自然是不可取的,正确的做法应该是去医院验个血,确诊后再对症下药。

让我们回想一下我们一般是如何调试程序的:通常是在没有数据的情况下依靠主观臆断来瞎蒙,而不是考虑问题到底是什么引起的!毫无疑问,调优程序性能问题的时候,同样需要对症下药。好消息是 Brendan D. Gregg 发明了 火焰图 ,可以一针见血的指出程序的性能瓶颈,坏消息是除了  OpenResty 社区 ,很少看到还有其他人使用火焰图。

常见的火焰图类型有 On-CPU , Off-CPU ,还有 Memory , Hot/Cold , Differential 等等。下面给出某个 PHP 程序的 On-CPU 类型的火焰图例子:

白话火焰图

Flame Graph

关于火焰图详细的介绍可以参考 Blazing Performance with Flame Graphs ,简而言之:整个图形看起来就像一团跳动的火焰,这也正是其名字的由来。燃烧在火苗尖部的部分就是 CPU 这在执行的操作,不过需要说明的是颜色是随机的,本身并没有特殊的含义,纵向表示调用栈的深度,横向表示消耗的时间。因为调用栈在横向会按照字母排序,并且同样的调用栈会做合并,所以一个格子的宽度越大越说明其是瓶颈。综上所述,主要就是看那些比较宽大的火苗,特别留意那些类似平顶山的火苗。

要生成火焰图,必须要有一个顺手的 Tracer 工具,如果操作系统是 Linux 的话,那么选择通常是 perf , systemtap 中的一种。其中 perf 相对更常用,多数 Linux 都包含了它,有兴趣的读者稍后可以参考  Linux Profiling at Netflix 中的介绍,尤其是里面关于如何处理 Broken stacks 问题的描述,建议多看几遍,而 systemtap 相对更强大,不过缺点是你需要先学会它本身的编程语言,如果你和我一样觉得麻烦,那么我强烈推荐你使用春哥的  nginx-systemtap-toolkit ,乍一看名字你可能会误以为这个工具包是 nginx 专用的工具,实际上这里面很多工具适用于任何 C/CPP 语言编写的程序:

  • sample-bt :用来生成 On-CPU 火焰图的采样数据( DEMO )
  • sample-bt-off-cpu :用来生成 Off-CPU 火焰图的采样数据( DEMO )

那么什么时候使用 On-CPU 火焰图?什么时候使用 Off-CPU 火焰图呢?取决于当前的瓶颈到底是什么,如果是 CPU 则使用 On-CPU 火焰图,如果是 IO 或锁 则使用 Off-CPU 火焰图。如果无法确定,那么可以通过压测工具来确认:通过压测工具看看能否让 CPU 使用率趋于饱和,如果能那么使用 On-CPU 火焰图,如果不管怎么压,CPU 使用率始终上不来,那么多半说明程序被 IO 或锁卡住了,此时适合使用 Off-CPU 火焰图。如果还是确认不了,那么不妨 On-CPU 火焰图和 Off-CPU 火焰图都搞搞,正常情况下它们的差异会比较大,如果两张火焰图长得差不多,那么通常认为 CPU 被其它进程抢占了。

在采样数据的时候,最好通过压测工具对程序持续施压,以便采集到足够的样本。关于压测工具的选择,如果选择 ab 的话,那么务必记得开启 -k 选项,以避免耗尽系统的可用端口。此外,我建议尝试使用诸如 wrk 之类更现代的压测工具。

请按照 官方说明 来安装。需要着重说明的是,当你安装 kernel-devel 和 kernel-debuginfo 的时候,务必保证所安装的版本和当前内核版本一致,以 CentOS 为例:

shell> yum install yum-utils
shell> yum install kernel-devel
shell> debuginfo-install kernel

当生成的火焰图中有很多十六进制的乱码时,那么意味着对应程序缺失了 debuginfo,可以借助 gdb 来确认这一点,方法如下所示:

shell> gdb -p <PID>

好消息是如果缺失了某些 debuginfo,那么 gdb 会在结尾提示你用 debuginfo-install 命令来安装,坏消息是如果你直接运行多半没有效果,因为 CentOS 缺省没有激活对应的仓库,所以需要在「/etc/yum.repos.d/CentOS-Debuginfo.repo」中设置 enabled=1。

要想熟练的使用火焰图的话,最好的方法就是多看别人的例子。春哥在微博上发过很多例子,这里我列举最具代表性的一个,版权自然归春哥所有:

微博来源:通过 Off-CPU 火焰图可以发现有一个使用互斥锁的 HTTP Cache 检查代码让绝大部分的 Off-CPU 时间(70%)都花在了等待进程锁上:

白话火焰图

微博来源:在移除了那个引发互斥锁瓶颈的历史代码之后,从图上我们可以清楚地看到 open() 系统调用是下一个最明显的性能瓶颈:

白话火焰图

微博来源:启用 nginx 的 open_file_cache 指令可以对打开的文件句柄进行缓存,从而节约昂贵的 open() 系统调用。但是缓存容量并不是越大越好,比如当达到 20000 个元素的容量时,共享内存的锁就成了瓶颈。

白话火焰图

心得:如果没有火焰图,我们往往会在解决一个问题后引入另一个问题。

实际使用火焰图的时候,因为 perf / systemtap 本身对系统性能影响较小,所以我们可以在线上随时采样数据来分析性能,我们甚至可以写一个脚本,自动化定期绘制系统运行状况的火焰图,如此一来,即便发生性能故障时我们没有第一时间在现场,也可以随时根据火焰图历史快照来确诊问题的根源。

燃烧吧,火焰图!

原文  http://huoding.com/2016/08/18/531
正文到此结束
Loading...