mysql火焰图_【性能】如何使用perf和火焰图分析系统性能？

一、实验环境

二、实验案例分析

安装完成后&＃xff0c;我们先在第一个终端&＃xff0c;执行下面的命令运行案例&＃xff0c;也就是一个最基本的 Nginx 应用&＃xff1a;

运行 Nginx 服务并对外开放 80 端口

# docker run -itd --name&＃61;nginx -p 80:80  nginx

然后&＃xff0c;在第二个终端&＃xff0c;使用 curl 访问 Nginx 监听的端口&＃xff0c;确认 Nginx 正常启动。

假设 192.168.0.30 是 Nginx 所在虚拟机的 IP 地址&＃xff0c;运行 curl 命令后&＃xff0c;你应该会看到下面这个输出界面&＃xff1a;

#  curl http://192.168.0.30/

接着&＃xff0c;还是在第二个终端中&＃xff0c;运行 hping3 命令&＃xff0c;模拟 Nginx 的客户端请求&＃xff1a;

#  hping3 -S -p 80 -i u10 192.168.0.30

现在&＃xff0c;我们再回到第一个终端&＃xff0c;你应该就会发现异常——系统的响应明显变慢了。

我们不妨执行 top&＃xff0c;观察一下系统和进程的 CPU 使用情况&＃xff1a;

从 top 的输出中&＃xff0c;你可以看到&＃xff0c;两个 CPU 的软中断使用率都超过了 30%&＃xff1b;而 CPU 使用率最高的进程&＃xff0c;正好是软中断内核线程 ksoftirqd/0 和 ksoftirqd/1。

虽然&＃xff0c;我们已经知道了 ksoftirqd 的基本功能&＃xff0c;可以猜测是因为大量网络收发&＃xff0c;引起了 CPU 使用率升高&＃xff1b;但它到底在执行什么逻辑&＃xff0c;我们却并不知道。

对于普通进程&＃xff0c;我们要观察其行为有很多方法&＃xff0c;比如 strace、pstack、lsof 等等。但这些工具并不适合内核线程&＃xff0c;比如&＃xff0c;如果你用 pstack &＃xff0c;或者通过 /proc/pid/stack 查看 ksoftirqd/0(进程号为 9)的调用栈时&＃xff0c;分别可以得到以下输出&＃xff1a;

那还有没有其他方法&＃xff0c;来观察内核线程 ksoftirqd 的行为呢&＃xff1f;

既然是内核线程&＃xff0c;自然应该用到内核中提供的机制。回顾一下我们之前用过的 CPU 性能工具&＃xff0c;我想你肯定还记得 perf &＃xff0c;这个内核自带的性能剖析工具。

perf 可以对指定的进程或者事件进行采样&＃xff0c;并且还可以用调用栈的形式&＃xff0c;输出整个调用链上的汇总信息。

我们不妨就用 perf &＃xff0c;来试着分析一下进程号为 9 的 ksoftirqd。

#  perf record -a -g -p 9 -- sleep 30

#################################################################

# man perf

# man 1 perf-record

perf-record - Run a command and record its profile into perf.data

-a, --all-cpus        System-wide collection from all CPUs (default if no target is specified).

-g                       Enables call-graph (stack chain/backtrace) recording.

-p, --pid&＃61;      Record events on existing process ID (comma separated list).

##################################################################

稍等一会儿&＃xff0c;在上述命令结束后&＃xff0c;继续执行 perf report命令&＃xff0c;你就可以得到 perf 的汇总报告。

按上下方向键以及回车键&＃xff0c;展开比例最高的 ksoftirqd 后&＃xff0c;你就可以得到下面这个调用关系链图&＃xff1a;

从这个图中&＃xff0c;你可以清楚看到 ksoftirqd 执行最多的调用过程。

虽然你可能不太熟悉内核源码&＃xff0c;但通过这些函数&＃xff0c;我们可以大致看出它的调用栈过程。

我们的猜测对不对呢&＃xff1f;

实际上&＃xff0c;我们案例最开始用 Docker 启动了容器&＃xff0c;而 Docker 会自动为容器创建虚拟网卡、桥接到 docker0 网桥并配置 NAT 规则。

这一过程&＃xff0c;如下图所示&＃xff1a;

当然了&＃xff0c;前面 perf report 界面的调用链还可以继续展开。

不幸的是我的屏幕不够大&＃xff0c;如果展开更多的层级&＃xff0c;最后几个层级会超出屏幕范围。

这样&＃xff0c;即使我们能看到大部分的调用过程&＃xff0c;却也不能说明后面层级就没问题。

那么&＃xff0c;有没有更好的方法&＃xff0c;来查看整个调用栈的信息呢&＃xff1f;

火焰图

针对 perf 汇总数据的展示问题&＃xff0c;Brendan Gragg 发明了火焰图&＃xff0c;通过矢量图的形式&＃xff0c;更直观展示汇总结果。

下图就是一个针对 MySQL 的火焰图示例。

图片来自 Brendan Gregg 博客

这张图看起来像是跳动的火焰&＃xff0c;因此也就被称为火焰图。

要理解火焰图&＃xff0c;我们最重要的是区分清楚横轴和纵轴的含义&＃xff1a;

上面 MySQL 火焰图的示例&＃xff0c;就表示了 CPU 的繁忙情况&＃xff0c;这种火焰图也被称为 on-CPU 火焰图。

如果我们根据性能分析的目标来划分&＃xff0c;火焰图可以分为下面这几种&＃xff1a;

了解了火焰图的含义和查看方法后&＃xff0c;接下来&＃xff0c;我们再回到案例&＃xff0c;运用火焰图来观察刚才 perf record 得到的记录。

火焰图分析

首先&＃xff0c;我们需要生成火焰图。我们先下载几个能从 perf record 记录生成火焰图的工具&＃xff0c;这些工具都放在 https://github.com/brendangregg/FlameGraph 上面。

你可以执行下面的命令来下载&＃xff1a;

#  git clone https://github.com/brendangregg/FlameGraph

#  cd FlameGraph

安装好工具后&＃xff0c;要生成火焰图&＃xff0c;其实主要需要三个步骤&＃xff1a;

执行 perf script &＃xff0c;将 perf record 的记录转换成可读的采样记录&＃xff1b;

执行 stackcollapse-perf.pl 脚本&＃xff0c;合并调用栈信息&＃xff1b;

执行 flamegraph.pl 脚本&＃xff0c;生成火焰图。

不过&＃xff0c;在 Linux 中&＃xff0c;我们可以使用管道&＃xff0c;来简化这三个步骤的执行过程。

假设刚才用 perf record 生成的文件路径为 /root/perf.data&＃xff0c;执行下面的命令&＃xff0c;你就可以直接生成火焰图&＃xff1a;

# perf script -i  /root/perf.data | ./stackcollapse-perf.pl --all | ./flamegraph.pl > ksoftirqd.svg

执行成功后&＃xff0c;使用浏览器打开 ksoftirqd.svg &＃xff0c;你就可以看到生成的火焰图了。

如下图所示&＃xff1a;

根据刚刚讲过的火焰图原理&＃xff0c;这个图应该从下往上看&＃xff0c;沿着调用栈中最宽的函数来分析执行次数最多的函数。

这儿看到的结果&＃xff0c;其实跟刚才的 perf report 类似&＃xff0c;但直观了很多&＃xff0c;中间这一团火&＃xff0c;很明显就是最需要我们关注的地方。

我们顺着调用栈由下往上看(顺着图中蓝色箭头)&＃xff0c;就可以得到跟刚才 perf report 中一样的结果&＃xff1a;

不过最后&＃xff0c;到了 ip_forward 这里&＃xff0c;已经看不清函数名称了。

所以我们需要点击 ip_forward&＃xff0c;展开最上面这一块调用栈&＃xff1a;

这样&＃xff0c;就可以进一步看到 ip_forward 后的行为&＃xff0c;也就是把网络包发送出去。根据这个调用过程&＃xff0c;再结合我们前面学习的网络收发和 TCP/IP 协议栈原理&＃xff0c;这个流程中的网络接收、网桥以及 netfilter 调用等&＃xff0c;都是导致软中断 CPU 升高的重要因素&＃xff0c;也就是影响网络性能的潜在瓶颈。

不过&＃xff0c;回想一下网络收发的流程&＃xff0c;你可能会觉得它缺了好多步骤。

比如&＃xff0c;这个堆栈中并没有 TCP 相关的调用&＃xff0c;也没有连接跟踪 conntrack 相关的函数。实际上&＃xff0c;这些流程都在其他更小的火焰中&＃xff0c;你可以点击上图左上角的“Reset Zoom”&＃xff0c;回到完整火焰图中&＃xff0c;再去查看其他小火焰的堆栈。

所以&＃xff0c;在理解这个调用栈时要注意&＃xff0c;从任何一个点出发、纵向来看的整个调用栈&＃xff0c;其实只是最顶端那一个函数的调用堆栈&＃xff0c;而非完整的内核网络执行流程。

另外&＃xff0c;整个火焰图不包含任何时间的因素&＃xff0c;所以并不能看出横向各个函数的执行次序。

到这里&＃xff0c;我们就找出了内核线程 ksoftirqd 执行最频繁的函数调用堆栈&＃xff0c;而这个堆栈中的各层级函数&＃xff0c;就是潜在的性能瓶颈来源。这样&＃xff0c;后面想要进一步分析、优化时&＃xff0c;也就有了根据。

当时&＃xff0c;我们从软中断 CPU 使用率的角度入手&＃xff0c;用网络抓包的方法找出了瓶颈来源&＃xff0c;确认是测试机器发送的大量 SYN 包导致的。而通过今天的 perf 和火焰图方法&＃xff0c;我们进一步找出了软中断内核线程的热点函数&＃xff0c;其实也就找出了潜在的瓶颈和优化方向。

其实&＃xff0c;如果遇到的是内核线程的资源使用异常&＃xff0c;很多常用的进程级性能工具并不能帮上忙。这时&＃xff0c;你就可以用内核自带的 perf 来观察它们的行为&＃xff0c;找出热点函数&＃xff0c;进一步定位性能瓶。当然&＃xff0c;perf 产生的汇总报告并不够直观&＃xff0c;所以我也推荐你用火焰图来协助排查。

实际上&＃xff0c;火焰图方法同样适用于普通进程。比如&＃xff0c;在分析 Nginx、MySQL 等各种应用场景的性能问题时&＃xff0c;火焰图也能帮你更快定位热点函数&＃xff0c;找出潜在性能问题。

CPU火焰图和内存火焰图&＃xff0c;在生成数据时有什么不同&＃xff1f;

CPU 火焰图和内存火焰图&＃xff0c;最大的差别其实就是数据来源的不同&＃xff0c;也就是函数堆栈不同&＃xff0c;而火焰图的格式还是完全一样的。

火焰图的结构是一样的&＃xff0c;只是函数堆栈不一样&＃xff0c;内存火焰图侧重于内存管理函数的调用栈。

内存火焰图生成perf.data数据时&＃xff0c;perf record加哪些选项&＃xff1f;

要加上内存管理相关的事件(函数)&＃xff0c;比如 perf record -e syscalls:sys_enter_mmap -a -g -- sleep 60

三、参考

内核线程 CPU 利用率太高&＃xff0c;我该怎么办&＃xff1f;

https://time.geekbang.org/column/article/86330

SVG 图像入门教程

https://www.ruanyifeng.com/blog/2018/08/svg.html

SVG 简介

https://www.runoob.com/svg/svg-intro.html

如何读懂火焰图&＃xff1f;

http://www.ruanyifeng.com/blog/2017/09/flame-graph.html

Linux程序性能分析和火焰图

https://www.cnblogs.com/pugang/p/10659301.html

Linux下用火焰图进行性能分析

https://blog.csdn.net/gatieme/article/details/78885908

火焰图介绍

https://book.aikaiyuan.com/linux/www.lijiaocn.com/linux/chapter1/04-flame-graphs.html

火焰图性能分析 perf

https://www.jevic.cn/2019/03/03/perf

perf &＃43; 火焰图分析程序性能

https://www.cnblogs.com/happyliu/p/6142929.html

使用 Perf 和火焰图分析 CPU 性能

http://senlinzhan.github.io/2018/03/18/perf

利用火焰图分析程序性能瓶颈

https://blog.angelmsger.com/%E5%88%A9%E7%94%A8%E7%81%AB%E7%84%B0%E5%9B%BE%E5%88%86%E6%9E%90%E7%A8%8B%E5%BA%8F%E6%80%A7%E8%83%BD%E7%93%B6%E9%A2%88