如何确定 BAM 数据库的瓶颈

首先备份好你本地的数据库，方法如下。

1、用APMServ5.2.6(网站上面有下载)带的phpmyadmin 进行备份恢复。

A、运行APMServ5.2.6， 点击右边的“管理MySql 数据库”。服务器填写127.0.0.1:3306,

登入名称：root,密码为空进行登录。在左边是数据库列表。点击你的数据库。点导出、拉到

最下面把“另存为文件”打勾。点执行。这样你就可以备份你的数据库了。

2、运行mySQL-Front 备份恢复你的数据库。

A、新建一个登录。

信息栏中随便写一下名字。标识你的登录信息。

B、点击连接栏，分别填好：

服务器：服务器的IP

端 口：一般为3306

C、点击注册栏，分别填好：

用 户：你申请的数据库的用户名(如果是本地一般为root)，

密 码：数据库的密码(本地为空)

数据库：你申请的数据库名。

填写好这些信息后点击“确定”这样就能链接到你的远程数据库了。左边这个远程数据。

服务器的一些数据库，点击你的数据库后等待链接。直至返回所有数据，你便能打开你的数据库。

中的数据表了。在这里你可以修改你的数据表结构，删除填加数据等(小心 *** 作)。

D、右键点击你的数据库进行备份(输出)数据，有几种备份的类型，一般选sql。

    具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。

   为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？

    相信大部分做数据库运维的朋友，都遇到这种情况。 数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert *** 作， 需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？

dba此时心中有无限的疑惑，到底是什么原因呢? 磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？ 还是数据库内部出问题？昨天不是还好好的吗？

 当数据库出现响应时间不稳定的时候，我们在 *** 作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO. 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么 *** 作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？

如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。

在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。

咱们先来提问题。 buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。

提问. 数据页不在buffer bool 里面该怎么办？

  回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool, 图片中显示

buffer_read_page函数栈的顶层是pread64(),调用了 *** 作系统的读函数。

buf_read_page的代码

 如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的 *** 作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer 中，无法直接使用该数据页，必须等待 *** 作系统完成IO .

再接着上面的回答提问：

当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？   代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。

试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool, 这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。 等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。

通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。

再继续扩展问题： 如果会话线程A 经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。

由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。

再回头来看上面的问题，mysql数据库出现性能下降时，可以看到 *** 作系统有读IO。 原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写 *** 作是不堵塞执行sql的会话线程的。所以，即使看到 *** 作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在 *** 作系统上基本看不到读的IO。  当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。

以国产数据库的发展来看，瓶颈主要集中在两个方面，一是研发，二是生态。

在研发方面，数据库研发技术起点高，难度大，一个成熟的数据库产品要具备深厚的技术积累和沉淀才能逐渐走向市场。国内很多厂商为求速成，要么基于一个现有的开源系统改进，要么从其他厂商购买源码授权，虽然起步比较快，但是产品架构几乎不可能调整，短期内也不可能掌握其核心技术，因此遇到客户新需求这样的问题时难以快速响应。

由此可见，要想实现数据库技术突破，只有靠自主研发，在实际应用场景中不断发现问题，从而革新技术，实现突破。国产数据库发展的几十年间，从“可用”、“试着用”到“好用”、“喜欢用”的方向不断发展，产品的架构、性能、功能、安全等方面都有了很大进步，国人在对待国产基础软件的态度上也有所转变。国产数据库要想快速发展，也需要在国家核高基等政策的推动下，在建立中国自主产权的软件国产化的重大主题的呼唤下，让国产数据库在一系列的项目中不断磨合，促进其产品的优化和成熟，使其更能适应市场，满足用户需求。

在生态方面，国产数据库生态建设困难，打破以国外品牌为主导的生态圈尤其困难。当前国外知名数据库在业内处于绝对领先地位，短期内无法撼动国际巨头的地位。如今，国内数据库厂商多达几十家，局面还有些混乱，单凭任何一家企业的力量难以打破国外市场的垄断，需要有“国家队”出现，集中投入财力物力，形成几家大型的国产数据库企业，深化数据库的市场化程度，集中力量牵头建设生态圈，共同推进我国的信息化建设。

---