性能测试如何确定数据库是否是瓶颈

    具体问题具体分析，举例来说明为什么磁盘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，数据库的性能会非常差。

ehcache主要是对数据库访问的缓存,相同的查询语句只需查询一次数据库,从而提高了查询的速度

oscache 主要是对页面的缓存,可以整页或者指定网页某一部分缓存,同时指定他的过期时间,这样在此时间段里面访问的数据都是一样的

hibernate2以前提倡用ehcache

hibernate3后提倡oscache,

另外,团IDC网上有许多产品团购,便宜有口碑

因为Redis具有在数据存储中快速读写数据的能力，所以它比关系型数据库更具有性能优势。但是，关键值数据存储是简单的;它们没有一个类似于

SQL的查询语言或者结构化的数据模型。相反，它们有一个把键值作为与数值相关的标识符来使用的简单字典或哈希模式。管理员使用这些键来进行数值的存储和

检索。

键值存储是简单快速的，它可用于实现丰富数据模型和关系型数据库查询功能的良好匹配。但是，有时候还是使用键值与关系型数据库的组合为好。此外，还有很多商业支持的键值数据库，包括Redis、Riak和Areospike等。

为了运行一个优化热门查询性能的Redis缓存，首先应确定你希望缓存的查询结果。其中，应重点关注最常用的和最耗时的查询，然后确定应缓冲查询中的数据。为简便起见，缓存查询返回的所有列值。

为键值定义一个命名约定;可以使用行主键和列名的组合来构造密钥。例如，其主键ID为 198278的 产品描述可以‘198278:descry’的键值进行存储。确保你的命名规则是简单和规则驱动的，以便于使用最少的代码来实现键的程序化创建。

接下来，确定是运行Redis缓存作为自助管理服务还是运行亚马逊的ElastiCache。运行用户自己的Redis实例将赋予管理人员对缓存的完全控制权。而这一控制权意味着灵活性，例如当有超出容量的情况出现时，管理人员有使用现有保留实例的权力。

此外，当用户想要把应用程序从一家云计算供应商迁移至另一家时，他们会发现完整的管理控制权限是非常有用的。

如果用户选择运行一个自助管理的Redis实例，可下载服务器。Redis的客户端支持30种以上编程语言——从Java和Python到Prolog和Smalltalk。

已经使用AWS环境的企业可能会想要使用ElastiCache。除了诸如托管打补丁这样的优点之外，亚马逊ElastiCache支持一系列高速

缓存优化的节点类型，具体包括从中型到2X的m3节点、从大型到8X的r3节点以及从微型到中型的t2节点。ElastiCache还支持一些上一代的节

点类型，例如选择m1、m2、t1和c1节点。

ElastiCache还支持多个可用区。如果有一个节点发生故障，一个读 *** 作复制节点将取代故障节点。任何需要确保应用程序运行的DNS变更都是

自动完成的，同时会创建一个新的读 *** 作副本。ElastiCache允许基于单位时间使用率的按需定价模式，以及一年期或三年期预付费的节点使用条款。完

整定价清单可以在这里找到。

如果使用Redis缓存和亚马逊ElastiCache，那么就可以从AWS管理控制台启动一个集群。除了设置Redis服务外，还需要修改应用程

序代码以便于能够使用缓存。一个常用的模式就是，检查缓存中是否存在有一个键值，如果没有就执行一个SQL查询以检索数据，然后将其存储在缓存中。当缓冲

存满时，可以配置Redis删除旧数据，这样就不需要用户使用专门的代码来处理缓存存满的情况了。

无论大型或小型应用，灵活的缓存可以说不仅大大减轻了服务器的压力，而且因为更快速的用户体验而方便了用户。

Android的apk可以说是作为小型应用，其中99%的应用并不是需要实时更新的，而且诟病于蜗牛般的移动网速，与服务器的数据交互是能少则少，这样用户体验才更好，这也是我们有时舍弃webview而采用json传输数据的原因之一。

采用缓存，可以进一步大大缓解数据交互的压力，特此，我们简略列举一下缓存管理的适用环境：

1 提供网络服务的应用

2 数据更新不需要实时更新，但是哪怕是3-5分钟的延迟也是可以采用缓存机制。

3 缓存的过期时间是可以接受的(不会因为缓存带来的好处，导致某些数据因为更新不及时而影响产品的形象等)

带来的好处：

1 服务器的压力大大减小

2 客户端的响应速度大大变快(用户体验)

3 客户端的数据加载出错情况大大较少，大大提高了应有的稳定性(用户体验)

4 一定程度上可以支持离线浏览(或者说为离线浏览提供了技术支持)

一、缓存管理的方法

这里的缓存管理的原理很简：通过时间的设置来判断是否读取缓存还是重新下载。

里面会有一些细节的处理，后面会详细阐述。

基于这个原理，目前鄙人见过的两种比较常见的缓存管理方法是:数据库法和文件法。

二、数据库法缓存管理

这种方法是在下载完数据文件后，把文件的相关信息如url，路经，下载时间，过期时间等存放到数据库，下次下载的时候根据url先从数据库中查询，如果查询到当前时间并未过期，就根据路径读取本地文件，从而实现缓存的效果。

从实现上我们可以看到这种方法可以灵活存放文件的属性，进而提供了很大的扩展性，可以为其它的功能提供一定的支持；

从 *** 作上需要创建数据库，每次查询数据库，如果过期还需要更新数据库，清理缓存的时候还需要删除数据库数据，稍显麻烦，而数据库 *** 作不当又容易出现一系列的性能，ANR问题，实现的时候要谨慎，具体作的话，但也只是增加一个工具类或方法的事情。

还有一个问题，缓存的数据库是存放在/data/data/<package>/databases/目录下，是占用内存空间的，如果缓存累计，容易浪费内存，需要及时清理缓存。

当然这种方法从目前一些应用的实用上看，我没有发现什么问题。

本文我侧重强调第二种方法，第一种方法的实现，就此掠过。

三、文件法缓存管理

这种方法，使用FilelastModified()方法得到文件的最后修改时间，与当前时间判断是否过期，从而实现缓存效果。

实现上只能使用这一个属性，没有为其它的功能提供技术支持的可能。

*** 作上倒是简单，比较时间即可。本身处理也不容易带来其它问题，代价低廉。

四、文件法缓存管理的两点说明

1 不同类型的文件的缓存时间不一样。

笼统的说，不变文件的缓存时间是永久，变化文件的缓存时间是最大忍受不变时间。

说白点，文件内容是不变的，直到清理，我们是可以永远读取缓存的。

配置文件内容是可能更新的，需要设置一个可接受的缓存时间。

2 不同环境下的缓存时间标准不一样。

无网络环境下，我们只能读取缓存文件，哪怕缓存早就过期。

WiFi网络环境下，缓存时间可以设置短一点，一是网速较快，而是流量不要钱。

移动数据流量环境下，缓存时间可以设置长一点，节省流量，就是节省金钱，而且用户体验也更好。

举个例子吧，最近本人在做的一个应用在wifi环境下的缓存时间设置为5分钟，移动数据流量下的缓存时间设置为1小时。

这个时间根据自己的实际情况来设置：数据的更新频率，数据的重要性等。

五、何时刷新

开发者一方面希望尽量读取缓存，用户一方面希望实时刷新，但是成都网站制作响应速度越快越好，流量消耗越少越好，是一个矛盾。

其实何时刷新我也不知道，这里我提供两点建议：

1 数据的最长多长时间不变，对应用无大的影响。

比如，你的数据更新时间为1天，则缓存时间设置为4~8小时比较合适，一天他总会看到更新，如果你觉得你是资讯类应用，再减少，2~4小时，如果你觉得数据比较重要或者比较受欢迎，用户会经常把玩，再减少，1~2小时，依次类推。

为了保险起见，你可能需要毫无理由的再次缩减一下。

2 提供刷新按钮。

上面说的保险起见不一定保险，最保险的方法使在相关界面提供一个刷新按钮，为缓存，为加载失败提供一次重新来过的机会，有了这个刷新按钮，我们的心也才真的放下来。

以上就是关于性能测试如何确定数据库是否是瓶颈全部的内容，包括:性能测试如何确定数据库是否是瓶颈、oscache对数据库缓存，各位大侠们，有谁对这方面比较熟悉，就是在网页设置缓存，在数据库更新时刷新，谢谢、如何用Redis缓存改善数据库查询性能等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！