转载

SQL Server里等待统计(Wait Statistics)介绍

在今天的文章里我想详细谈下SQL Server里的统计等待(Wait Statistics),还有她们如何帮助你立即为什么你的SQL Server当前很慢。一提到性能调优,对我来说统计等待是SQL Server了最重要的概念。

查询为什么等待

在SQL Server里每次你执行1个查询,查询总需要等待。什么?查询总需要等待?是的,你没有看错:但给你执行1个查询时,查询总需要等待。为什么查询需要等待的原因是SQL Server通过所谓的 等待统计(Wait Statistics) 来跟踪的。在我进入等待统计(Wait Statistics)细节内容前,我想谈下SQL Server里查询总需要等待的原因。在SQL Server里查询发生等待有2个原因:

  • 资源等待
  • 协同调度(Cooperative Scheduling)等待

我们来详细看下这2类等待。当你等待外部资源时会发生 资源等待(Resource Wait) 。这里我想你一些例子。每次一个查询从缓存池请求1个页时,如果这个页没被缓存的话,缓存区管理器需要到你的存储进行异步I/O操作,从你的物理存储读取页到缓存池。而且访问物理存储会非常慢。由于这个原因SQL Server会拿掉你查询的CPU周期,查询只会等待直到异步I/O操作完成(同事其它查询可以更有效的使用CPU资源)。最后你的查询继续它的执行。

当你需要获取锁时也会发生同样的事情——当你想要读或修改数据时。当其它人已经获得了不兼容的锁,你的查询需要去等待直到锁可以获得。同时SQL Server会再次拿掉你的CPU周期,查询需要去等待直到其它查询的不兼容锁释放掉,这样的话查询本身可以获得请求的锁。

除资源等待外,SQL Server查询还会因SQLOS(SQL Server操作系统(OS))内部实现的 协同调度(Cooperative Scheduling) 而等待。SQL Server绕过Windows系统的抢占式调度(Cooperative Scheduling),调度它的线程本身。因为这样的设计SQL Server会更容易扩展,并为你提供更好的吞吐量。当1个查询在CPU上积极运行时,SQL Server本身就可以决定,当1个查询从CPU上拿掉时,SQL Server也可以决定,这样的话另1个查询可以在那个CPU上活跃继续它的查询执行。由于这个原因,一旦查询溢出所谓的 量(Quantum) ,SQL Server就会把你的查询从CPU上拿掉。

量定义了查询在CPU上可以活跃花费的时间片(time slice)。在SQL Server里这个时间片是4毫秒长。这就是说一旦查询完成它的工作超出4毫秒,SQL Server就会把你的查询从CPU上拿掉。因此在SQL Server里查询总是要等待。如果没有资源等待,溢出量就会踢入,查询会在CPU上睡着(going off)。你的查询总会等待!

查询生命周期

我们我们知道了在SQL Server里查询总需要等待。我们来进一步看下它。当你执行1个查询,这个查询会进入3个不同的状态,如下图中所示:

SQL Server里等待统计(Wait Statistics)介绍  

我们来详细说下这3个状态。只要你的查询在你的CPU上积极运行,这个查询是在 RUNNING 状态。 RUNNING 状态意味着你的查询当前正进行一些工作。进入这个状态一直是你的首要目标。当SQL Server把你的查询从CPU上拿掉时,然后这个查询移入了 SUSPENDED 状态。查询只要 SUSPENDED 状态需要都会等待,直到请求的资源可用(回想下从你物理存储读取的页,或者不能立即获得的不兼容锁)。

当请求的资源可用时,然后SQL Server把你的查询移入RUNNABLE状态。RUNNABLE状态意味着你的查询准备好了继续执行,但它需要另外必需的东西:在它上面运行的CPU。当现在没有可用的CPU时(因为其它查询当前在RUNNING状态),查询需要在RUNNABLE状态花费一些时间。 最后当CPU变成可用时,查询移入RUNNING状态,然后一切轮回继续。一个简单的查询在执行期间,可以运行上几百次,甚至几千次的查询生命周期(query life cycle )。

分析等待统计(Wait Statistics)

所有这些状态事务被SQL Server跟踪,并通过等待统计反馈给我们。SQL Server通过DMV  sys.dm_os_wait_stats 来披露这些等待统计(Wait Statistics)。从这个DMV返回的每条记录都是SQL Server里的1个等待原因。在SQL Server 2014里你共有771个不同的为什么查询会等待的原因。什么?771个不同原因?跟我开玩笑吧?那是很多的!没错!但一般来说你只需要处理一些特定的等待原因,因为我们每个人几乎都处理SQL Server里同样的性能问题:

  • 缓慢的存储子系统
  • 不好的索引设计
  • 锁/阻塞问题
  • 低效的并行执行计划
  • CPU压力
  • ……

当在面前有一个运行慢的SQL Server,第一步我总看下等待统计里的详细信息,因为它们告诉我为什么SQL Server里查询在等待。但SQL Server里的等待统计只是个症状,不是问题根源本身!或许SQL Server通过等待统计告诉你在过去有一些因阻塞情形的等待。但可能是不是你有一个不好的索引设计,缺失了一个非常重要的非聚集索引导致了阻塞情形?有了额外的非聚集索引你提供SQL Server额外的数据访问路径,是否你的阻塞情形就可以轻松解决?这只是症状并非根源的1个例子(很多中的)。

小结

在这个文章里我给你概况介绍了在SQL Server里为什么查询会等待,还有这些等待如何通过等待统计来跟踪。等待统计里最重要的事情是SQL Server里它只告诉你症状,并不是问题根源。作为故障排除人,你的工作是读和理解统计等待,最后挖出你SQL Server里更多的信息来找出潜在的问题根源。

感谢关注!

正文到此结束
Loading...