如何判断MSSQL数据库磁盘出现了瓶颈

Posted 2023-05-05

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

参考技术A 问题：

我们可能经常会遇到SQLServer数据库频繁关闭的情况。在分析了内存和CPU使用情况后，我们需要继续调查根源是否在I/O。我们应该如何识别SQLServer是否有I/O相关的瓶颈？

解决：

当数据页经常从缓冲池中移进移出的时候，I/O子系统就会成为SQLServer性能问题的关键因素之一。事务日志和tempdb同样也会产生重大的I/O压力。因此，你必须确保你的I/O子系统能按照预期运行。否则你将会成为响应时间增长和频繁超时的受害者。在这篇文章中，将描述如何使用内置工具识别I/O相关瓶颈，并提供一些磁盘配置的方法：

性能计数器（Performance Monitor）：

可以使用性能计数器来检查I/O子系统的负荷。下面的计数器可用于检查磁盘性能：

PhysicalDisk Object:Avg.DiskQueue
Length：计算从物理磁盘中的平均读和写的请求队列。过高的值代表磁盘操作处于等待状态。当这个值在SQLServer峰值时长期超过2，证明需要注意了。如果有多个硬盘，就需要把这些数值除以2。比如，有4个硬盘，且队列为10，那么平均值就是10/4=2.5，虽然也证明需要关注，但不能使用10这个值。

Avg.Disk Sec/Read和Avg.Disk
Sec/Write：显示从磁盘读或者写入磁盘的平均时间。10ms内是很好的表现，20以下还算能接受。高于此值证明存在问题。

Physical Disk:%Disk
Time：在磁盘忙于读或者写请求的时候持续时间的比率。根据拇指定律，此值应该小于50%。

Disk Reads/Sec和Disk
Writes/Sec计数器显示出在磁盘中读写操作的速率。这两个值应该小于磁盘能力的85%。当超过此值，磁盘的访问时间将以指数方式增长。

可以通过以下方式来计算逐渐增长的负载的能力。一种方法是使用SQLIO。你应该找到吞吐量比较稳定，但缓慢增长。

可以使用以下公式来计算RAID配置：

Raid 0: I/O per disk = (reads + writes) / number
ofdisks
Raid 1: I/O per disk = [reads + (writes*2)] /
2
Raid 5: I/O per disk = [reads + (writes*4)] / number of
disks
Raid
10: I/O per disk = [reads +
(writes*2)] / number of disks

比如：对于RAID 1，如果得到下面的计数器：

Disk Reads/sec = 90
Disk
Writes/sec =75

根据公式：[reads + (writes*2)] / 2 or [90 + (75*2)] /
2 = 120I/Os每个磁盘。

动态管理视图（DMVs）：

有很多游泳的DMVs可以用于检查I/O瓶颈：

当一个页面被用于读或者写访问且页面在缓冲池中不存在或不可用时，会引发一个I/O闩锁等待（I/O
latch），它会在PAGEIOLATCH_EX/PAGEIOLATCH_SH（具体根据请求类型而定）。这些等待表明一个I/O瓶颈。可以使用sys.dm_os_wait_stats找到闩锁等待的信息。如果你保存了SQLServer正常运行下的waiting_task_counts和wait_time_ms值，并且于此次的值做对比，可以识别出I/O问题：

select *

from sys.dm_os_wait_stats

where wait_type like
'PAGEIOLATCH%'

order by wait_type asc

挂起的I/O请求可以在下面查询中查到，并且用于识别那个磁盘负责的这个瓶颈：
select database_id,
file_id,
io_stall,
io_pending_ms_ticks,
scheduler_address
from sys.dm_io_virtual_file_stats(NULL, NULL) iovfs,
sys.dm_io_pending_io_requests as iopior
where iovfs.file_handle = iopior.io_handle

磁盘碎片（Disk Fragmentation）：

建议你检查磁盘碎片和配置用于SQLServer实例的磁盘。在NTFS文件系统中的碎片会产生严重的性能影响。磁盘需要经常整理碎片并且指定整理碎片计划。研究表明，一些情况下SAN在整理碎片后性能更差。因此，SAN必须根据实际情况对待。

NTFS上的索引碎片同样能引起高I/O好用。但是这和在SANs中的效果是不一样的。

磁盘配置/最佳实践：

常规情况，你应该把日志文件和数据文件分开存放以获得更好的性能。对于重负载的数据文件（包括tempdb）的I/O特性是随机读取。对于日志文件，是顺序访问的，除非事务需要回滚。

对于内置磁盘仅仅可以用于数据库日志文件，因为它们对顺序I/O有很好的性能，但是对随机I/O性能低下。

数据库的数据和日志文件应该放在对应专用的磁盘中。确保良好的性能。建议日志文件放在两个内置磁盘，并配置为RAID
1。数据文件驻留在仅用于给SQLServer访问的SAN系统中，并只被查询和报表控制。特殊访问应该被禁止。

写缓冲在可能的情况下应该被允许，并保证断电也能使用。

为了尽可能保证对于OLTP系统的I/O瓶颈影响最小化，不应该把OLAP和OLTP环境混合。并且保证你的代码优化及有合适的索引来避免不必要的I/O。

出现这四种情况，才是考虑分库分表的时候！

前言

当数据库的数据量过大，大到一定的程度，我们就可以进行分库分表。那么基于什么原则，什么方法进行拆分，这就是本篇所要讲的。

数据库瓶颈

不管是 IO 瓶颈还是 CPU 瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载的活跃连接数的阈值。

在业务 Service 来看， 就是可用数据库连接少甚至无连接可用，接下来就可以想象了（并发量、吞吐量、崩溃）。

IO 瓶颈：

• 第一种：磁盘读 IO 瓶颈，热点数据太多，数据库缓存放不下，每次查询会产生大量的 IO，降低查询速度→分库和垂直分表；

• 第二种：网络 IO 瓶颈，请求的数据太多，网络带宽不够→分库。

CPU 瓶颈：

• 第一种：SQL 问题：如 SQL 中包含 join，group by，order by，非索引字段条件查询等，增加 CPU 运算的操作→SQL 优化，建立合适的索引，在业务 Service 层进行业务计算；

• 第二种：单表数据量太大，查询时扫描的行太多，SQL 效率低，增加 CPU 运算的操作→水平分表。

分库分表

水平分库

概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。

结果：

• 每个库的结构都一样；

• 每个库中的数据不一样，没有交集；

• 所有库的数据并集是全量数据。

场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库的情况下。

分析：库多了，IO 和 CPU 的压力自然可以成倍缓解。

水平分表

概念：以字段为依据，按照一定策略（hash、range 等），讲一个表中的数据拆分到多个表中。

结果：

• 每个表的结构都一样；

• 每个表的数据不一样，没有交集，所有表的并集是全量数据。

场景：系统绝对并发量没有上来，只是单表的数据量太多，影响了 SQL 效率，加重了 CPU 负担，以至于成为瓶颈，可以考虑水平分表。

分析：单表的数据量少了，单次执行 SQL 执行效率高了，自然减轻了 CPU 的负担。

垂直分库

概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。

结果：

• 每个库的结构都不一样；

• 每个库的数据也不一样，没有交集；

• 所有库的并集是全量数据。

场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块的情况下。

分析：到这一步，基本上就可以服务化了。例如：随着业务的发展，一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。

再者，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。

垂直分表

概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表中（主表和扩展表）。

结果：

• 每个表的结构不一样；

• 每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；

• 所有表的并集是全量数据。

场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大，以至于数据库缓存的数据行减少，查询时回去读磁盘数据产生大量随机读 IO，产生 IO 瓶颈。

分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能经常会查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表，这样更多的热点数据就能被缓存下来，进而减少了随机读 IO。

拆了之后，要想获取全部数据就需要关联两个表来取数据。但记住千万别用 Join，因为 Join 不仅会增加 CPU 负担并且会将两个表耦合在一起（必须在一个数据库实例上）。

关联数据应该在 Service 层进行，分别获取主表和扩展表的数据，然后用关联字段关联得到全部数据。

分库分表工具

常用的分库分表工具如下：

• Sharding-JDBC

• TSharding

• Atlas

• Cobar

• MyCAT

• Oceanus

• Vitess

各种工具的利弊自查。

分库分表带来的问题

分库分表能有效缓解单机和单表带来的性能瓶颈和压力，突破网络 IO、硬件资源、连接数的瓶颈，同时也带来一些问题，下面将描述这些问题和解决思路。

事务一致性问题

1）分布式事务

当更新内容同时存在于不同库找那个，不可避免会带来跨库事务问题。跨分片事务也是分布式事务，没有简单的方案，一般可使用“XA 协议”和“两阶段提交”处理。

分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间，导致事务在访问共享资源时发生冲突或死锁的概率增高。

随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平扩展的枷锁。

2）最终一致性

对于那些性能要求很高，但对一致性要求不高的系统，往往不苛求系统的实时一致性，只要在允许的时间段内达到最终一致性即可，可采用事务补偿的方式。

与事务在执行中发生错误立刻回滚的方式不同，事务补偿是一种事后检查补救的措施，一些常见的实现方法有：对数据进行对账检查，基于日志进行对比，定期同标准数据来源进行同步等。

跨节点关联查询 Join 问题

切分之前，系统中很多列表和详情表的数据可以通过 Join 来完成，但是切分之后，数据可能分布在不同的节点上，此时 Join 带来的问题就比较麻烦了，考虑到性能，尽量避免使用 Join 查询。

解决的一些方法：

1）全局表

全局表，也可看做“数据字典表”，就是系统中所有模块都可能依赖的一些表，为了避免库 Join 查询，可以将这类表在每个数据库中都保存一份。这些数据通常很少修改，所以不必担心一致性的问题。

2）字段冗余

一种典型的反范式设计，利用空间换时间，为了性能而避免 Join 查询。

例如，订单表在保存 userId 的时候，也将 userName 也冗余的保存一份，这样查询订单详情顺表就可以查到用户名 userName，就不用查询买家 user 表了。

但这种方法适用场景也有限，比较适用依赖字段比较少的情况，而冗余字段的一致性也较难保证。

3）数据组装

在系统 Service 业务层面，分两次查询，第一次查询的结果集找出关联的数据 id，然后根据 id 发起器二次请求得到关联数据，最后将获得的结果进行字段组装。这是比较常用的方法。

4）ER 分片

关系型数据库中，如果已经确定了表之间的关联关系（如订单表和订单详情表），并且将那些存在关联关系的表记录存放在同一个分片上，那么就能较好地避免跨分片 Join 的问题。

可以在一个分片内进行 Join，在 1：1 或 1：n 的情况下，通常按照主表的 ID 进行主键切分。

跨节点分页、排序、函数问题

跨节点多库进行查询时，会出现 limit 分页、order by 排序等问题。

分页需要按照指定字段进行排序，当排序字段就是分页字段时，通过分片规则就比较容易定位到指定的分片；当排序字段非分片字段时，就变得比较复杂。

需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。

最终返回给用户如下图：

上图只是取第一页的数据，对性能影响还不是很大。但是如果取得页数很大，情况就变得复杂的多。

因为各分片节点中的数据可能是随机的，为了排序的准确性，需要将所有节点的前N页数据都排序好做合并，最后再进行整体排序，这样的操作很耗费 CPU 和内存资源，所以页数越大，系统性能就会越差。

在使用 Max、Min、Sum、Count 之类的函数进行计算的时候，也需要先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总再次计算。

全局主键避重问题

在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据库自生成 ID 无法保证全局唯一。

因此需要单独设计全局主键，避免跨库主键重复问题。这里有一些策略：

1）UUID

UUID 标准形式是 32 个 16 进制数字，分为 5 段，形式是 8-4-4-4-12 的 36 个字符。

UUID 是最简单的方案，本地生成，性能高，没有网络耗时，但是缺点明显，占用存储空间多。

另外作为主键建立索引和基于索引进行查询都存在性能问题，尤其是 InnoDb 引擎下，UUID 的无序性会导致索引位置频繁变动，导致分页。

2）结合数据库维护主键 ID 表

在数据库中建立 sequence 表：

CREATE TABLE `sequence` (  

  `id` bigint(20) unsigned NOT NULL auto_increment,  

  `stub` char(1) NOT NULL default '',  

  PRIMARY KEY  (`id`),  

  UNIQUE KEY `stub` (`stub`)  

) ENGINE=MyISAM;

stub 字段设置为唯一索引，同一 stub 值在 sequence 表中只有一条记录，可以同时为多张表生辰全局 ID。

使用 MyISAM 引擎而不是 InnoDb，已获得更高的性能。MyISAM 使用的是表锁，对表的读写是串行的，所以不用担心并发时两次读取同一个 ID。

当需要全局唯一的 ID 时，执行：

REPLACE INTO sequence (stub) VALUES ('a');  

SELECT LAST_INSERT_ID();  

此方案较为简单，但缺点较为明显：存在单点问题，强依赖 DB，当 DB 异常时，整个系统不可用。配置主从可以增加可用性。另外性能瓶颈限制在单台 MySQL 的读写性能。

另有一种主键生成策略，类似 sequence 表方案，更好的解决了单点和性能瓶颈问题。

这一方案的整体思想是：建立 2 个以上的全局 ID 生成的服务器，每个服务器上只部署一个数据库，每个库有一张 sequence 表用于记录当前全局 ID。

表中增长的步长是库的数量，起始值依次错开，这样就能将 ID 的生成散列到各个数据库上。

这种方案将生成 ID 的压力均匀分布在两台机器上，同时提供了系统容错，第一台出现了错误，可以自动切换到第二台获取 ID。

但有几个缺点：系统添加机器，水平扩展较复杂；每次获取 ID 都要读取一次 DB，DB 的压力还是很大，只能通过堆机器来提升性能。

3）Snowflake 分布式自增 ID 算法

Twitter 的 Snowfalke 算法解决了分布式系统生成全局 ID 的需求，生成 64 位 Long 型数字。

组成部分如下：

• 第一位未使用；

• 接下来的 41 位是毫秒级时间，41 位的长度可以表示 69 年的时间；

• 5 位 datacenterId，5 位 workerId。10 位长度最多支持部署 1024 个节点；

• 最后 12 位是毫秒内计数，12 位的计数顺序号支持每个节点每毫秒产生 4096 个 ID 序列。

数据迁移、扩容问题

当业务高速发展、面临性能和存储瓶颈时，才会考虑分片设计，此时就不可避免的需要考虑历史数据的迁移问题。

一般做法是先读出历史数据，然后按照指定的分片规则再将数据写入到各分片节点中。

此外还需要根据当前的数据量个 QPS，以及业务发展速度，进行容量规划，推算出大概需要多少分片（一般建议单个分片的单表数据量不超过 1000W）。

什么时候考虑分库分表

能不分就不分

并不是所有表都需要切分，主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”，避免“过度设计”和“过早优化”。

分库分表之前，先尽力做力所能及的优化：升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后，在考虑分库分表。

数据量过大，正常运维影响业务访问

这里的运维是指：

• 对数据库备份，如果单表太大，备份时需要大量的磁盘 IO 和网络 IO；

• 对一个很大的表做 DDL，MySQL会锁住整个表，这个时间会很长，这段时间业务不能访问此表，影响很大；

• 大表经常访问和更新，就更有可能出现锁等待。

随着业务发展，需要对某些字段垂直拆分

这里就不举例了，在实际业务中都可能会碰到，有些不经常访问或者更新频率低的字段应该从大表中分离出去。

数据量快速增长

随着业务的快速发展，单表中的数据量会持续增长，当性能接近瓶颈时，就需要考虑水平切分，做分库分表了。

>>>>

参考资料

• http:///www.cnblogs.com/butterfly100/p/9034281.html

• https://www.cnblogs.com/littlecharacter/p/9342129.html

  
  

  作者丨坚持就是胜利

来源丨 https://juejin.im/post/5dc77a9451882559465e390b

dbaplus社群欢迎广大技术人员投稿，投稿邮箱： [e-mail]

---

云时代下数据库将迎来怎样的革新与创变？ 金融行业核心数据库迁移与建设如何安全平稳展开？ 开源技术如何在实际业务场景中发挥实力？ 10月30日，DAMS中国数据智能管理峰会将在上海举办，专设【数据库分场】，部分议题如下：

• 《从自研演进看分布式数据库》中国银联 云计算中心云组件总监 周家晶

• 《开源数据库MySQL在民生银行的应用实践》民生银行 项目经理 徐春阳

• 《如何构建数据库容器化PaaS》爱可生 资深方案架构师 徐阳
  

立即扫码享受 限时优惠 ，在数据库变迁中站稳脚跟！