MySQL太慢？试试这些诊断思路和工具

第一步，我们来看一下数据源，Linux 给我们提供的数据源包括操作系统内核态提供的观测点和用户态提供的观测点，MySQL 很早之前就提供了用户态的观测点。

第二步，如何把数据抽出来。以下这些工具中大家最熟悉的应该是 perf 和 ftrace，sysdig 也有人在用，其它的可能有所耳闻，这是从操作系统里抽取数据的方法。

第三步，数据处理前端，前端常用的也是 perf 和 ftrace。如果大家对 perf 很熟悉的话会知道 perf 出来的数据是一个树形的数据，并可以跟这棵树进行交互，比如说: 查看某个函数运行了多久，哪一个函数的时间最长，这个是数据处理前端。

我们来对比一下常规的四类系统观测工具：ftrace, perf_events，eBPF 和 Systemtap，这四个工具到底有什么不同，看看 Linux 为什么提供这么多观测工具。

ftrace：ftrace 是 sysfs 中的一个桩，通过这个桩内核提供了一种观测的形式——把想观测的函数签名打到这个桩里，然后操作系统就会提供这个函数运行的状况。ftrace 的结构如左图, 数据处理前端和采集端是 ftrace, 数据源是下面这一堆。

perf：常用的 perf 的原理是操作系统提供了一个系统调用可以将数据写到一个缓存中, 然后客户端把这些数据端抽取出来然后呈现在显示器上。

eBPF：这是本文想重点推荐的。以上两种方案一种是操作系统提供的文件系统上的桩，一种是操作系统提供的系统调用，而 eBPF 是将一段代码直接插到操作系统内核某一个位置上的机制。

Systemtap：它的原理是将一段 C 的代码编译成一个内核模块，然后将这个模块嵌到内核里边去，它不是由内核提供的一个机制，而是由内核的模块机制提供的一种功能。

介绍了这四种观测工具的不同，大家在选取观测工具的时候就知道应该怎么选。

这四种观测工具对系统伤害最轻的是谁？

对系统伤害最轻的是系统调用，这是系统承诺出来的服务。然后是 ftrace，这是系统在文件系统层面提供的一个口，告诉你可以通过这个口跟系统交互。

对系统侵入性最强的是谁？

对系统侵入性最强的应该是 eBPF，因为它直接将一根代码嵌入到系统里边去做，最不稳定的应该是 System Tap，因为它是系统的一个模块, 又提供了非常复杂的功能。

上图是 eBPF 的架构图，eBPF 先将一段程序编译成二进制代码，然后插入到操作系统里，操作系统运行这段代码的时候，将采集到的数据吐到操作系统本身的空间里，然后再做统一返回。

eBPF 结构最核心的部分在于把代码插入到操作系统中运行，它需要做各种安全保护才能完成这一点，所以这也是这个机制复杂的地方。

下面引用一个开源的 eBPF 脚本集 bcc, 快速看一下 eBPF 能做什么, 这些功能都是开箱即用的。

bcc (eBPF 脚本集) 使用举例

MySQL 的请求延迟分析：

一个 MySQL 承担了很多业务，上千个并发˙中，哪一个 SQL 最慢，到底有哪些 SQL 在一秒以上，除了 slow log 以外，还可以用这种方法来看。

这个命令的结果分为三列，它的第一列是请求的延迟，指数级递增，单位是微秒，中间一列是它的命中数，如果有一个请求命中了 64-127 微秒这个区间，命中数会加一，最后一列是它的分布图，它在同一个报告里提供了数值的方式和图的方式，可以很容易看到结果。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!