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

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

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

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

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

bcc (eBPF 脚本集) 使用举例

MySQL 的请求延迟分析：

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

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

对于这台服务器来说，我下了一个 select 的性能压力，它大部分的请求集中于 64 到 127 微秒之间。这个数据库的性能可能还不错。

再来看另外一种压力，我下了一个 select+insert 的混合压力在一个数据库里，它的图又变了，它呈现了一个非常好的双峰图，我将两个峰值用另外一种颜色标明，这两个峰值的意思是很有可能有混合压力在一个数据库里，或者是上面的这部分压力是命中了某些缓存，而下面的某些压力是由于没有命中缓存，导致这部分请求更慢一些, 形成另一个峰值，所以通过这种峰值分析可以看到数据库大概的一个运行状态。

（编辑：惠州站长网）

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