你们好,欢迎回到性能调优培训的第22周。上周我谈了SQL Server里的基线,今天咱们继续,谈下SQL Server里的等待和I/O延迟统计。当我进行SQL服务器健康检查时,我总会使用这2个维度全局掌握下SQL Server的健康情况。html
在SQL Server里每次你执行一个查询,查询会等待。初次看这个看起来很惨淡,但其实有一个很是好的缘由,在SQL Server里总会等待。每次一个查询等待,SQL Server经过所谓的等待统计(Wait Statistics)来跟踪这些等待。在咱们讨论等待统计自己前。我想介绍下为何在执行期间,查询总会等待。等待的概念主要基于2个原则:数据库
咱们来详细看下这2个。每次查询等待一个当前不可用的资源——例如在缓存池理还没缓存的页,或者由于另外一个不兼容的锁而不能得到的锁——查询会进入SQL Server里所谓的挂起(Suspended)状态。查询在挂起状态一直等待直到资源变成可用。缓存
当资源变成可用时,查询进入所谓的可执行(Runnable)状态,再次等待,知道CPU变成可用。当CPU是可用时,查询最后进入运行(Running)状态,执行到资源再次变成不可用。当这个发生时,查询再次进入挂起(Suspended)状态。下图显示了这个查询生命周期。服务器
另外查询也会因为在SQLOS(SQL Server操做系统)里SQL Server实现的协同调度(Cooperative Scheduling)而等待。SQL Server经过使用特定的WIN32 API功能调度它的线程。协同调度意味着当一个查询自己超过近4ms的额(quantum )时,它从CPU上撤离。由于这个实现方式,在SQL Server里查询总会等待:一旦一个资源尚不可用,或者查询已超过了它的额——查询就会进入挂起(Suspended)状态并等待。oop
每次当一个等待状况发生时,等待时间被SQL Server经过等待统计(Wait Statistics)自动跟踪。SQL Server经过DMV sys.dm_os_wait_stats 报告这些信息。经过这个DMV返回的每一行都表明SQL Server里的一个特定等待——所谓的等待类型(Wait Type)。经过评估等待统计,SQL Server告诉你什么是最突出的等待类型。而后你能够聚焦这个等待类型并找出内部问题根源,还有对于这个等待类型为何等待时间如此高。性能
除了等待统计外另外一个很是重要的是SQL Server也会报告的I/O延迟统计(I/O Latency Statistics)。有了这些延迟时间很容易找出你的SQL Server实例哪一个文件有延迟时间。SQL Server经过DMF sys.dm_io_virtual_file_stats来报告这些信息。你能够传入database_id和file_id。若是你对这2个值都提供NULL值的话,你会获得SQL Server实例(数据和日志)全部查询相关文件的延迟统计。
spa
对于这个DMF最重要的是io_stall_read_ms和io_stall_write_ms列。自上次SQL Server重启后,对你的存储进行读写操做所发生的累积延迟时间。若是你把这2个值除以num_of_read和num_of_writes列,你就获得从SQL Server角度来讲,对于磁盘读写的平均延迟时间。这对于你的存储子系统的故障排除很是方便。操作系统
若是这个DMF报告很是高的延迟时间,你不该该简单的跑到存储供应商那里并买更快的存储。第一步你总要想下为何你有这么高的延迟时间。当我在不一样的系统上使用这个DMF时,TempDb总会报告很高的延时。但这也不意味着你要把TempDb移到更快的存储,例如SSD硬盘。第一步总要思考下,对于你特定的数据库“为何”你有这么高的延迟时间。若是是TempDb的话你能够尝试最小化TempDb的使用——例如应用合理的索引策略来摆脱执行计划里的排序和哈希运算符,这2个运算符会蔓延到TempDb。线程
等待统计和I/O延迟统计直报告你症状,你的任务是找出性能问题的内在根源,分析它,最后解决它。日志
在今天的性能调优培训里咱们详细讨论了SQL Server里的等待统计和I/O延迟统计。对于性能监控和故障排除来讲,这2个DMVs/DMFs很是重要,由于你从中能够找出SQL Server当前在哪些领域有性能问题。下周咱们会详细谈下TempDB,我把它叫作SQL Server的公共厕所。请继续关注!