MySQL性能诊断实践之系统观测工具

本文根据黄炎在2018年8月3日在【2018 MySQL技术交流大会 · 上海站】现场演讲内容整理而成。

黄炎，爱可生研发总监，深刻钻研分布式数据库相关技术，擅长业界相关MySQL中间件产品和开发，以及分布式中间件在企业内部的应用实践。

摘要：今天我带来的分享是系统观测工具，有所关联但不涉及MySQL自身的这样一个话题。

分享大纲：

1. MySQL 慢的诊断思路
2. 系统观测工具介绍
3. bcc (eBPF脚本集) 使用举例
4. eBPF 使用方法/限制

今天我带来的分享是系统观测工具，跟MySQL相关，但不是MySQL，选择这个话题最主要的缘由是今天4场演讲，刚才是官方的专家来介绍MySQL的新特性，后面还有两位专家，一位是介绍MySQL在真实业务中的大规模应用，还有一位是介绍源码，留给个人空间并非不少，因此选择了一个跟MySQL有所关联但不涉及MySQL自身的话题。

首先想请问一下你们，若是遇到MySQL慢的话你们的第一印象是什么，MySQL数据库若是性能不行的状况下，你们的处理手法是怎样？

我咨询了一些同行, 获得了如下反馈，第一反应是再试一次，第二个反应是优化一下SQL，第三个反应是咱们调大buffer pool，而后开始换硬件了，换一下SSD，而后实在不行了咱们找个搜索引擎问一下说“MySQL慢怎么办”。

若是你们用的是国内的搜索引擎的话，搜索引擎会推荐某某知道或者某某乎, 推荐一些MySQL调优经验, 调大参数A, 调低参数, 诸如此类，相似的网站能告诉你MySQL慢怎么办。

咱们来分析一下这些现象背后隐藏的意义：

1.若是你们再试一次可以成功的话, 意味着你可能碰到了不可复现的外界因素的影响，致使MySQL会慢。
2.若是优化SQL能解决，就意味着SQL的执行复杂度远远大于它的需求复杂度。
3.若是调大buffer pool能解决，就意味着MySQL碰到了自身的某些限制。
4.若是换SSD能解决，那么意味着服务器资源受到了必定的限制。
5.若是须要搜索引擎，意味着调优这事已经变成了玄学。

因此今天我想向你们介绍的是四部份内容：

1.MySQL 慢的诊断思
2.系统观测工具介绍
3.bcc (eBPF脚本集) 使用举例
4.eBPF 使用方法/限制

第一部分，咱们向你们介绍一下常规的MySQL诊断慢的思路，也是业界的常规思路。

第二部分，是今天介绍的主要命题 -- 系统观测工具的相关内容，咱们会大概了解一下什么叫系统观测工具。

第三部分，给你们介绍一个脚本集，这个脚本集是开源的，开箱即用而且能够帮助你们快速诊断MySQL的一些问题，咱们直接使用10个例子 快速地介绍一下这个脚本集能为咱们作到什么。

最后，咱们介绍一下eBPF的使用方法和脚本结构。任何一个好用的东西必定有它本身的限制，不然它就太完美了，因此咱们也会介绍一下它的限制究竟是怎样的。

1.MySQL 慢的诊断思路

咱们先来看第一个阶段，MySQL慢的诊断思路，通常咱们会从三个方向来作：

第一个方向是MySQL内部的观测
第二个方向是外部资源的观测
第三个方向是外部需求的改造

1.1 MySQL 内部观测

咱们来看MySQL内部的观测，经常使用的观测手段是这样的，从上往下看，第一部分是Processlist，看一下哪一个SQL压力不太正常，第二步是explain，解释一下它的执行计划，第三步咱们要作Profilling，若是这个SQL能再执行一次的话, 就作一个Profilling，而后高级的DBA会直接动用performance_schema ，MySQL 5.7 之后直接动用sys_schema，sys_schema是一个视图，里面有便捷的各种信息，帮助你们来诊断性能。再高级一点，咱们会动用innodb_metrics进行一个对引擎的诊断。

除了这些手段之外，你们还提出了一些乱七八糟的手段，我就不列在这了，这些是常规的一个MySQL的内部的状态观测的思路。除了这些之外，MySQL还陆陆续续提供了一些暴露本身状态的方案，可是这些方案并无在实践中造成套路，缘由是学习成本比较高。

1.2 外部资源观测

外部资源观测这部分，我引用了一篇文章，这篇文章的二维码我贴在上面了。这篇文章是国外的一个神写的，标题是：60秒的快速巡检，咱们来看一下它在60秒以内对服务器到底作了一个什么样的巡检。一共十条命令，这是前五条，咱们一条一条来看。

1.uptime，uptime告诉咱们这个机器活了多久，以及它的平均的负载是多少。
2.dmesg -T | tail，告诉咱们系统日志里边有没有什么报错。
3.vmstat 1，告诉咱们虚拟内存的状态，页的换进换出有没有问题，swap有没有使用。
4.mpstat -P ALL，告诉咱们CPU压力在各个核上是否是均匀的。
5.pidstat 1，告诉咱们各个进程的对资源的占用大概是什么样子。

咱们来看一下后五条：

首先是iostat-xz 1，查看IO的问题，而后是free-m内存使用率，以后两个sar，按设备网卡设备的维度，看一下网络的消耗状态，以及整体看TCP的使用率和错误率是多少。最后一条命令top，看一下大概的进程和线程的问题。

这个就是对于外部资源的诊断，这十条命令揭示了应该去诊断哪些外部资源。

1.3 外部需求改造

第三个诊断思路是外部的需求改造，我在这里引用了一篇文档，这篇文档是MySQL的官方文档中的一章，这一章叫Examples of Common Queries，文档中介绍了常规的SQL怎么写, 给出了一些例子。文章的连接二维码在slide上。

咱们来看一下它其中提到的一个例子。

它作的事情是从一个表里边去选取，这张表有三列，article、dealer、price，选取每一个做者的最贵的商品列在结果集中，这是它的最原始的SQL，很是符合业务的写法，可是它是个关联子查询。

关联子查询成本是很贵的，因此上面的文档会教你快速地把它转成一个非关联子查询，你们能够看到中间的子查询和外边的查询之间是没有关联性的。

第三步，会教你们直接把子查询拿掉，而后转成这样一个SQL，这个就叫业务改造，先后三个SQL的成本都不同，把关联子查询拆掉的成本，拆掉之后SQL会跑得很是好，但这个SQL已经不能良好表义了，只有在诊断到SQL成本比较高的状况下才建议你们使用这种方式。

为何它可以把一个关联子查询拆掉呢？

这背后的原理是关系代数，全部的SQL均可以被表达成等价的关系代数式，关系代数式之间有等价关系，这个等价关系经过变换能够把关联子查询拆掉。

上面的这篇文档是一个大学的教材，它从头教了关于代数和SQL之间的关系。而后一步步推导怎么去简化这句SQL。

第一，MySQL自己提供了不少命令来观察MySQL自身的各种状态，你们从上往下检通常能检到SQL的问题或者服务器的问题。

第二，从服务器的角度，咱们从巡检的脚本角度入手，服务器的资源就这几种，观测手法也就那么几种，咱们把服务器的资源所有都观察一圈就能够了。

第三，若是实在搞不定，需求方必定要按照数据库容易接受的方式去写SQL，这个成本会降低的很是快，这个是常规的MySQL慢的诊断思路。

2.系统观测工具介绍

咱们先从诊断思路的讨论切换到系统的观测工具，首先了解什么叫系统观测工具而且看一下它的举例，而后再回到诊断思路上，看看新的工具的引入能为咱们的思路到底带来怎样的改变。

先来看一下什么叫系统观测工具？援引这篇文档，二微码如上，这是一个外国人写的文档，我把这个文档拆开，中间描述了三件事情：

第一，系统观测工具的数据源来自于哪里；
第二，数据采集过程，由于采集的是系统的运行情况，因此到底如何采集这是一个难点；
第三，应该怎么看数据，是用图来看，仍是用表来看，它就叫数据处理前端；

第一步，咱们来看一下数据源，Linux给咱们提供的数据源是这几种，包括操做系统内核态提供的观测点和用户态提供的观测点，MySQL很早以前就提供了用户态的观测点。

第二步，怎么把数据抽出来，抽出来的时候，你们能够看到这些工具里边你们最熟悉的应该是perf和ftrace，而后sysdig也有人在用，其它的可能有所耳闻，这个是从操做系统里边抽取数据的方法。

第三步，数据处理前端，前端里边经常使用的也是perf和ftrace。若是你们对perf很熟悉的话会知道perf出来的数据是一个树形的数据，并能够跟这棵树进行交互，好比说: 查看某个函数运行了多久，哪个函数的时间最长，这个是数据处理前端。

咱们来对比一下常规的四类系统观测工具今天我要介绍的是第三类，eBPF，咱们过往经常使用的是第四个，前面这两个是通用工具，咱们来对比一下这四个到底有什么不一样，看看Linux到底为啥提供这么多观测工具。

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

第二，你们经常使用的perf，原理是操做系统提供了一个系统调用能够将数据写到一个缓存中, 而后客户端把这些数据端抽取出来而后呈如今显示器上。这个是perf的运行原理。

第三，eBPF是咱们今天要重点介绍的，eBPF的方案，跟刚才两种方案不同，刚才两种方案一种是操做系统提供的文件系统上的桩，一种是操做系统提供的系统调用，而eBPF是将一段代码直接插到操做系统内核某一个位置上的机制。

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

这是四种观测工具的不一样。

为何要介绍这四种观测工具的不一样，是由于你们在选取观测工具的时候就知道大概怎么选。

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

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

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

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

这张图是eBPF的架构图，eBPF先将一段程序编译成二进制代码，而后插到操做系统里边去，操做系统运行这段代码的时候，将采集到的数据吐到操做系统自己的一个空间里，而后再作统一返回，大概就是这样的一个结构。

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

3. bcc (eBPF脚本集) 使用举例

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

第一个例子，MySQL的请求延迟分析，一个MySQL承担了不少业务，上千个并发在那儿，哪个SQL最慢，到底有哪些SQL在一秒以上，除了slow log之外，还能够用这种方法来看。

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

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

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

若是能作得更好，你们能够抽检本身的数据库而后作环比图，好比说今天和昨天一样的时间，一样的业务压力下对数据库的延迟进行分析，若是数据库的延迟峰一直在日后延，就意味着数据库的状态在变得更糟糕一些。这是bcc第一个能作的事情，须要再次强调的是它开箱即用直接下载过来就可使用。

第二个例子，MySQL的慢查询，MySQL自己提供很好的慢查询，我干吗要用另一个机制来获取MySQL的慢查询呢？

咱们先看一下它的输出,其实跟MySQL自己的慢查询还要再简单一些。那么咱们为何要用另一种方式来获取慢查询呢？

由于它能作到这些事情，而MySQL的慢查询可能很难作，与MySQL的慢日志相比, 它能够低成本地完成:

1. 获取少许慢查询
2. 获取某种模式的慢查询
3. 获取某个用户的慢查询

好比说获取少许的慢查询，为何是少许呢？由于咱们不肯定如今的线上延迟是多少，慢查询只开一秒可能日志瞬间就被堆上去，性能就会下来，可是若是慢查询开个十秒左右，没有请求在这个区间命中，因此要一点一点的去调这个值，好比说线上1%的最慢的查询可以命中，可是在这个脚本里面，能够取必定区间的最大的几个查询把它拎出来。

经过脚本还能够命中某种模式的慢查询, 好比说咱们只关心update的慢查询, 那么获取select的结果就没有太大的意义，或者是我必定要获取某一些特定表的相关的查询，我均可以经过脚原本作。

第三种状况我想获取某个用户的慢查询，这个通常对于多租户系统，由于多租户系统我只想针对某一个用户进行慢查询分析的时候，这种脚本就比较好用，这是我想说的第二个例子。

以后的几个例子都跟IO相关，因此我引用了另一篇文档，这篇文档是Linux IO的堆栈图，右边是引用的二维码，这张堆栈图看起来很复杂，但这个实际上是2012年画的初版的IO堆栈图，如今IO堆栈图比这个要复杂不少，你们能够在这个网址上去体验一下。而后咱们把其中的关键元素抽出来，咱们看一下IO的堆栈大概是几个层次？

从MySQL开始，MySQL是运行在用户态中，它经过VFS层的接口，一个IO请求就下到内核态，而后从VFS转到真正的文件系统，以后IO请求会下到块设备层，在块设备层里边会经历IO的一个调度器，你们常见的MySQL的调优建议里面, 对于调度器的设置要么设成空要么设成deadline, 就是在这个位置起做用，最后经过SCSI接口, 将数据请求下到物理设备。

第三个例子，VFS延迟分析，咱们对每一层均可以经过脚本对它进行IO分析，好比说我能够对VFS作延迟分析。

对VFS作延迟分析，这是对数据库进行了一个写压力，你们能够明显看到一个双峰图，这是写的两个峰，是数据库对于内核的写压力的反馈。

这个意味着什么呢？这个可能意味着由于这部分的写是命中了操做系统文件系统的缓存，而下面这部分写是真正的写穿到设备的，因此他们俩的延迟不同，这是一个典型的双峰图，你们须要把两个峰拆开来去行这样的分析。

换一个说法，若是写压力都集中在这里，而没有第二个峰的状况下，需不须要去更换物理设备？有可能不须要，由于全部的东西都命中了操做系统的缓存。

第四个例子，Ext4 文件IO延迟分析，咱们以前看到的图是以磁盘设备为维度的。

那么我能不能按照文件维度去看究竟是哪一个文件的IO慢，这个脚本能够直接作到。 我下了一个最简单的写压力到数据库上。

红色标明的地方比非红色的地方的数值都要高，而它的共性在于都是数据文件，而非红色的部分都是各种的日志文件，这就是你们常说的日志文件是顺序写的，数据文件是随机写的，顺序写比随机写快, 就在这个延迟上体现了，因此经过这种观测方式你们能够观测到各个文件的写压力的平均延迟大概在什么水平上。

我用这个工具主要是用来抓住一些证据, 好比其余进程影响了数据库的IO。在这个地方故意用了DD，不是打车的滴滴，是写IO的DD，DD的IO压力就会被工具抓出来, 这就是铁的证据。这是我想介绍的第四个例子，它能够作基于文件的IO分析。

第五个例子，块设备的延迟分析，为何要补充一个块设备的延迟分析呢？由于从刚才的这些延迟分析上，延迟都是带有操做系统缓存的影响的，而经过这个脚本能够看出真实下到设备上的延迟是多少。

这是一个下到设备上的压力的状况, 大部分的延迟在32微秒到64微秒之间，我也不知道这个设备是好仍是很差，作IO压力的时候很难经过绝对值去判断这个事是好仍是很差，你们须要经过环比得出正确的结论。

这张双峰图, 是个人同事作出来的，他问我说这是个典型的双峰图，是否是IO出了问题设备出了问题，一组IO比另外一组IO的延迟明显要高。

那这个图到底有没有问题呢？这个图没有什么太大的问题，由于它的count很小。它真实的select下在到设备上的读只有五个请求，这五个请求里边明显有三个比其它的两个延迟要高一些，这个事儿不值得分析。大部分的请求所有都被InnoDB的buffer和操做系统的Cache所有都hold住了，因此这个事情是不值得分析的，你们经过这个图也能够完成刚才“需不须要更换设备, 更换设备之后MySQL会不会变得更快”的问题，在如图的状况下应该不会。

第六个例子，MySQL线程对文件的IO压力汇总，咱们看了刚才基于设备的、基于全局文件的IO压力分析，我想知道MySQL到底哪一根线程对IO形成了压力，是InnoDB负责刷数据的哪根线程,仍是正在导数据的线程。

这个脚本能够帮你们作到这个事情，看看这个脚本的输出结果是这样的，它最左边一列是TID，是线程号，最右边一列是文件，中间部分是它写的大小。在这样的一个数据库上，你们能够明显看到这个数据库出了什么问题。

即便没有my.cnf的内容也能知道这个数据库出了什么问题，它的问题可能在于开启了general log。这个是基于线程的，因此你们只要找到这两根线程, 就能知道这两根线程是哪一个业务下来的，这两根线程的SQL可能异常多, 因此general log一直在刷日志，刷成了如今这样子。这个是基于线程，而且基于文件的对IO的分析。

第七个例子，短生命周期的临时文件检测，这个你们不必定常见，MySQL会在某些状况下动用临时表, 若是SQL没写好就会建立临时表，这些临时表的生命周期很短，可是量很大，因此必定要写文件而不能内存里。

在这种状况下会对操做系统形成一些压力，而这个压力又不太好诊断，是由于临时文件的生存周期短，因此这个脚本能够帮你们提供这样的一个方案，这个方案的结果大概是这样子。

我作了一个临时表，这个临时表活了5.3秒左右，因而它展示在了脚本的结果里。若是你们扫描本身的线上MySQL发现这里有大量的东西说明在大量的使用临时表，若是IO压力在此时比较大, 就可能受了临时表的影响。

第八个例子，短链接分析，好一点的应用都会用链接池，可是咱们不少的时候没有那么好的运气，老碰到那么好的应用，因此常常业务会扔过来大量的短链接。

这个例子中, sysbench上了一个大并发，可是只活了300多毫秒，这些链接都只活了300多毫秒，反复运行这个sysbench就能够将数据库打死，创建一千个链接，300毫秒之后也会销毁，再创建一千个链接，你的业务就会忽上忽下，经过这个脚本就能够抓到这个压力从哪一个服务器来的，哪一个端口来的，而后把它搞定就能够了，这是数据库的短链接分析。

第九个例子，长链接分析，除了短链接分析，还有长链接分析，哪个业务端老在搞个人数据，老在往里写，总在往里读，搞的网络特别慢。

这个就能够帮你们提供这样的一个视角，这个就是长链接分析。它有读有写，都在这里，这是第九个脚本。

第十个例子，CPU offcpu 消耗分析。看看最后一个脚本，这个我须要介绍一下背景，什么叫offcpu，什么叫消耗分析，以及最终造成的图大概是什么样子。

为何咱们要对CPU的offcpu进行分析呢？

由于正常的状况下CPU的工做过程是这样子的，MySQL运行在操做系统的用户态。序运行过程当中会切入到内核态, 好比说程序进行了系统调用，比较好的状况是程序能够一直占着cpu，因此它一直都会在运行中，若是不太好的状况，好比说遇到了磁盘的IO，网络的IO，主动的睡眠，一些锁的阻塞，它就会陷入不占用CPU的状况，把CPU放弃了，而后让给了其它线程。

可是这个时候是否是意味着数据库工做良好？若是你们对MySQL只作onCPU的分析，这个阶段onCPU是0，不占CPU，可是由于IO是阻塞的，我想知道究竟是由于什么阻塞在这，这个就叫offcpu的分析，就是MySQL从内核态开始把CPU让出来，开始下台的时候，我想知道它为何下台，以及下台持续了多久，而后来进行这样的分析。

它最后的输出结果是这样的一个图，这个图叫火焰图而且这是一个冷火焰图，它的是offcpu的，你们常见的火焰图是火焰图, 是红色的, 指的是oncpu的分析。咱们特地把它作成了冷色的，这是offcpu的火焰图，很显然没有任何一我的能读得懂上面写的究竟是什么。因此我来介绍一下什么叫火焰图，火焰图是这样一个过程。

好比说对数据库进行采样，进行采样的过程当中，采了四个样，这四个样这个地方表明数据库的运行堆栈，而后它的运行堆栈是这样子，这样四个运行堆栈，而后在火焰图上他们就会被合并成这样子，他们四个都涉及到第一个调用是A，因此它会把A合并在一块儿，第二个调用有两个是B，把B合并在一块儿，最后你们看到的就是这样一个图，这个图变大之后，就会长成像一个火焰的样子，因此它就是Flame Graph。

这个是火焰图是怎么造成的，它是经过采样，而后把采样合并成一张图，而后你们在这个图上能得到什么信息，得到的信息是程序的入口多是A，由于全部的采样都过了A，其中B独立运行占了四分之一的时间，B之上C占了四分之一的时间，你们就能从这个图上快速的读出这个事情。

因此若是对这个程序要进行调优的话，你们会调到哪里，从哪里下手调优最直接方便？B独立运行了四分之一，C独立运行了四分之一，E独立运行四分之一，咱们惟一知道的是调优D是没有用的，由于D全部的时间都被E占用了，因此调优D无论怎么调它本身的时间是没有占用的，这个就是火焰图的基本原理。

咱们来看一个例子，这个例子是我从刚才的那个图上截出来的，这是offCPU分析中的一部分，它占了刚才那张图差很少25%的左右的大小，这个堆站从下往上读，最下面这个你们能读懂吧，innobase:index_read, 表示引擎在读索引树。而后往上读，不知道什么意思，mvcc不知道什么意思，无所谓，再往上读，Btr_...to_nth_level, 表示在读索引数的第n层，再往上读，我buffer上面开了一个页，它开始读页了，而后这个地方涉及到了fil_io, 为了读取这个页我开始读文件了，而后上面do_syscall_...进行了系统调用，而后到了VFS开始真实的进行这个系统调用。

若是这个堆栈出如今整个MySQL堆栈的25%，意味着什么呢？意味着MySQL花了25%的时间来读页，来从文件系统里边把这个页读出来，这个页是干什么用的？这个页是在索引中的，就即便不懂代码，读这些英文，大概也能分析出若是把磁盘换掉，或者是把buffer pool扩大，扩得很是大，而后开始加内存，最好的条件下能让这个数据库变快25%，可能可以把这个堆栈整个消掉，这个就是火焰图带给你们的IO分析的方法。

刚才咱们介绍了十个bcc相关的例子，这些例子都是现成的脚本，bcc这个工具能向你们提供的是一整套，能够观测这个操做系统的各个方面，好比说若是有东西被OOM kill掉了，而后内存有泄露的也能够看，而后这边有N多的其余的部分，这个基本上是咱们这几年发现的一个宝库，你们直接调用这些脚本就能够完成不少的别人完成不了的分析，它的技术用的是eBPF，就是咱们刚才介绍的系统观测工具。你们直接在github上直接搜就好了。

4.eBPF 使用方法/限制

若是这里边脚本知足不了要求, 那咱们能够本身写。这里咱们介绍一下脚本的写法以及eBPF的限制。

咱们拿刚才MySQL延迟分析举例，一个MySQL上面有一千个query，这些query大概都落在哪一个延迟时间里面那张图，为了完成这个需求, 我须要写两段程序，其中第一段程序是运行在内核里边的程序。

这段程序的逻辑是这样的，先在query开始的时候截获一下，让它记录一个时间戳，而后请求结束的时候再截获一下记录一个时间戳，而后把两个时间戳相减得到一个延迟，而后把这个延迟扔到结果集里边去，程序就完成了，正常思路吧。我用结束时间减开始时间，减一下获得一个延迟，而后把延迟扔到一个统计容器里面，这个事就结束了。这是我要写的第一个程序，是嵌到内核里的程序，可是须要一个外壳的程序负责嵌入。

这个外壳程序的逻辑也很是简单，把刚才那段内核的程序嵌到MySQL的观测点上，嵌到内核里面去，而后把结果集拿出来，打印出来就结束了，这是如何写一个eBPF的脚本，你们惟一须要作的事情就是这两个程序，而后运行一下。

这个程序有多长呢？这个程序就这么长，45行，可是我中间忽略了一些部分，这些部分是负责差错处理，它的核心就是这45行，而后你们只须要把如今的脚本拿下来抄一抄，改一改就能够完成不少的功能了。

咱们来聊聊限制，这么好的方法为何不少人不知道呢？

操做系统内核的限制，这个功能是Linux 4.4引进来的，可是在Linux 4.4上存在统计的bug，若是你们用那张分布图的话，会看到这个图上数不太对，咱们推荐的是Linux 4.9+，部分好用的功能是在4.13+上才开放，这个是eBPF最大的限制。怎么办呢？只能祝你们长寿吧！活到Linux 4.x内核能在生产环境上使用的那一天。

它的第二个最大的限制是MySQL的编译参数，MySQL虽然在很早很早的时候，已经提供了dtrace的观测点，这些观测点是公用的，可是它在默认的编译出来的官方发布的包里边是不带观测点编译的，因此在直接官方发布的二进制的包里边是用不了这个功能的，你们须要本身编译一下。编译的时候须要带这个参数，这个可能也是属于一个比较大的限制。

因此若是你们受到限制，咱们推荐换一个工具，systemtap 。

Linux 2.6就已经有了，可是我刚才说过，它的机制是写一个内核模块，这种机制其实不是特别稳定，它为了解决不是特别稳定的问题增长了若干限制，好比说能在内核中使用的内存大小有限制，采集频率也有限制，对整个内核的性能的影响的百分比也有限制，在这些限制参数都开起来的状况下，它仍是比较安全的。

可是不少观测功能好比说offCPU的火焰图，就必需要把这些限制关掉，一旦关掉内核就不是很稳定，因此这个工具，我没有敢把它的缺点写在上面由于确实是个好的工具，咱们也很难说它的这个缺点是个致命的缺陷，可是不太推荐在生产环境上使用，可是在测试环境上确实是很是好玩的一个工具，若是你们用不了eBPF的话能够用systemtap来作一些诊断。这是跟限制相关的部分。

而后有systemtap，有eBPF，你们就想知道有没有其它的选择的部分，这个图也是我偷来的，都是羊驼，就有这么多工具，你们能够去选择它。

至于怎么选择的话，你们直接谷歌一下有专门的文章教你们怎么来选择这些观测工具，可是总的来讲没有一个科学的思路，就是尝试，不停的尝试。

推荐一本书，全部的此次演讲里知识的来源都来源于这本书，咱们刚才说的bcc的脚本集的做者，这是他写的书，他还作了不少神同样的事情，强烈推荐给你们，这本书很早中文版就出版了，可是好像不少人读过的人不是不少。

除了中文版的书以外，再推荐一个文档，这篇文档是红帽的官方文档，不须要红帽企业的会员，免费能够读，叫：Performance Tuning Guide，它在第二节介绍了操做系统各类能够用的观测工具，覆盖了咱们的第一部分所说的全部的外部观测工具，以及咱们在中间所说的系统观测工具，都在这上面。可是我不太喜欢这个文档的缘由是由于它不多有原理分析，而都是在说这边有一个参数能够调，那边有一个参数能够调，若是你们想获取这部分的知识的话，这篇文档的质量也是异常的高，红帽我一直以为是一个卖文档顺便卖操做系统的公司。

我今天的全部的内容都已经呈现完了，谢谢！

PPT下载连接：github.com/actiontech/slides