优化方法论的第一步是在实例级别上找出什么类型的等待占用了大部分的等待时间,这可以通过查询动态管理图(DMV,dynamic management view)sys.dm_os_wait_stats
运行一下查询,将返回你的系统中的等待信息,并按类型排序。
SELECT wait_type , waiting_tasks_count , wait_time_ms , max_wait_time_ms , signal_wait_time_ms FROM sys.dm_os_wait_stats ORDER BY wait_type
这个DMV从服务器最后一次重新启动开始积累值,如果想重置他的值,可以运行一下代码
DBCC SQLPERF(‘sys.dm_os_wait_stats‘,CLEAR)
- DMV sys.dm_os_wait_stats包含一下属性:
1.wait_type , 2.waiting_tasks_count , 表示该类等待的数量 3.wait_time_ms , 以毫秒为单位的该类等待的总时间(该时间包含signal_wait_time_ms) 4.max_wait_time_ms , 5.signal_wait_time_ms 它是正在等待的线程从收到信号通知到其开始运行之间的时差。从线程收集到资源可用的信号开始,到线程得到CPU时间,开始使用资源位置经历的时间。可以想到,如果这个属性的值很高,通常就表示CPU存在问题。
- 与I/O相关的等待是最常见的等待(例如,IOLATCH等待),其中有几个原因,I/O通常是数据处理操作所涉及的最昂贵资源。而且,当查询或索引没有经过良好的设置或优化时,结果一定会造成大量的I/O。 数据库系统,不只是要关注CPU,还需要非常强健的I/O子系统。
- 对于网络相关的等待(例如:ASYNC_NETWORK_IO),他们的值过高,则表明可能存在网络问题。
时间: 2024-10-18 00:08:03