来自sql server的高磁盘I / O还是正在减慢sql server的速度？

我一直在与DBA和几个硬件专家争论我们SQL服务器上的性能问题。通常，一切都很好，但是在过去的几周中，我们在sql服务器中一直遇到巨大的延迟高峰。很明显，SQL Server正在磁盘I / O上等待。但是我一直被告知这是因为SQL Server请求异常高的I / O。事实并非如此。从运行中我可以看到没有异常，DBA关心的只是导致阻塞的原因，等等，这是没有用的。例如，我们看到的主要备份是对ASPState数据库的操作，我们正在使用它来管理Web服务器上的ASP会话状态。这些操作通常不会在Sp_who2活动结果上看到，因为它们发生得如此之快。数据库处于简单恢复模式，日志记录很少。但是，在这些延迟尖峰期间，我们可以看到对数据库的大量选择和更新操作被阻止或等待。我确定正在发生的事情是某人或某项作业正在运行某些操作，从而导致该数据库日志和数据文件使用的RAID阵列上的磁盘使用率很高。问题正在得到证明，因为没有人愿意承认他们所做的事情正在杀死我们的网站。

我的问题是什么性能计数器或我可以记录什么内容，这将有助于表明SQL Server正在等待I / O，但不是因为它要求的异常多，而是因为磁盘正忙于响应sql server的请求像往常一样快吗？

看一下以下perfmon计数器：

• SQL Server，缓冲区管理器对象：
  Page lookups/sec
Page reads/sec
Readahead pages/sec
• SQL Server，访问方法对象
  Full Scans/sec
Range Scans/sec
Skipped Ghosted Records/sec
• SQL Server，等待统计对象
  Page IO latch waits

驱动大量IO请求的SQL Server可以通过大量扫描，增加页面查找和页面读取以及增加页面IO闩锁等待来证实。值得一看的是sys.dm_exec_query_stats具有高物理读取计数的条目。他们可以迅速找出罪魁祸首。

通常，将问题作为性能故障排除问题来解决，遵循诸如Waits和Queues之类的方法是正确的方法。您的DBA似乎做对了，所以您应该听他的话。

首先使用Glenn Berry的诊断查询和Adam Machanic的SP_Whoisactive来查找实际发生的情况。

首先通过运行此查询来查看哪些数据库文件具有最大的IO瓶颈（由Glenn Berry查询）

SELECT  DB_NAME(fs.database_id) AS [Database Name] ,
        mf.physical_name ,
        io_stall_read_ms ,
        num_of_reads ,
        CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,
        io_stall_write_ms ,
        num_of_writes ,
        CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,
        io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,
        num_of_reads + num_of_writes AS [total_io] ,
        CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads
                                                          + num_of_writes ) AS NUMERIC(10,
                                                              1)) AS [avg_io_stall_ms]
FROM    sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
        INNER JOIN sys.master_files AS mf WITH ( NOLOCK ) ON fs.database_id = mf.database_id
                                                             AND fs.[file_id] = mf.[file_id]
ORDER BY avg_io_stall_ms DESC
OPTION  ( RECOMPILE );

然后运行此查询以查看服务器正在等待的十大事件（由Jonathan Kehayias查询）。您还会从Glenn Berry诊断查询中找到类似的查询。

SELECT TOP 10
        wait_type ,
        max_wait_time_ms wait_time_ms ,
        signal_wait_time_ms ,
        wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
        100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( ) AS percent_total_waits ,
        100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( ) AS percent_total_signal_waits ,
        100.0 * ( wait_time_ms - signal_wait_time_ms )
        / SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM    sys.dm_os_wait_stats
WHERE   wait_time_ms > 0 -- remove zero wait_time
        AND wait_type NOT IN -- filter out additional irrelevant waits
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'SQLTRACE_BUFFER_FLUSH',
  'CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT', 'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK',
  'SLEEP_BPOOL_FLUSH', 'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT',
  'FT_IFTSHC_MUTEX', 'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
  'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
  'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
  'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
  'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
  'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'WAITFOR',
  'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN', 'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC

一旦掌握了这些信息，解决问题就会容易得多。

顺便说一句，您可以在这里找到许多有关如何使用sp_whoisactive进行故障排除的文章。

正确地说：“问题正在得到证明”。看一下SQL Server：最小化磁盘I / O

它正在谈论以下DMV

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

参考文献：

1. 如何从SQL Server中检查IO子系统延迟
2. Glenn Berry的SQL Server性能-sys.dm_io_pending_io_requests