LoadRunner性能测试—SQL等待类型

　　本章节主要讲解“LoadRunner性能测试—SQL等待类型”，我们通常可能更多的去监控每个查询执行步骤所消耗的时间，但其实这些还不够，因为每个执行计划在执行前可能需要等待，而这些等待的时间是被消耗了，没有任何作用，所以如果能缩短等待时间显然可以提高SQL Server的性能。

　　SQL Server通过SQLOS(SQL Server Operating System)调度程序来管理用户请求执行，SQLOS则通过SCHEDULER、WORKER、TASK等对任务进行调度和处理。

　　默认情况下调度程序的数量与服务器中的逻辑CPU数量相同，即SCHEDULER个数与CPU个数相匹配，因为一个CPU某时刻只能运行一个调度程序，如果服务器中包含2个CPU，则调试程序数量为2，如果是双核的，那么调度程序为4，如果是双核且超线程的，则调度程序数量为8。只有拿到scheduler所有权的任务worker才能在这个逻辑CPU上运行。

　　使用以下查询语句可以查询到当前CPU数和SCHEDULER数。

　　SELECT cpu_count,scheduler_count FROM sys.dm_os_sys_info

　　结果如图11-2所示。

　　图11-2 CPU与SCHEDULER查询值

　　在调度程序内部，会话通常有三种状态：running、runnable和suspended，但会话只可能是这三种状态中的一种，在任何时刻，调度程序上只能有一个会话处于running状态，其它的会话都处于等待状态，存储在runnable队列之中，停止执行并将某等待的会话状态将改为suspended。会话三状态图如图11-3所示。　

　　图11-3 会话三种状态

　　WORKER (又称为WORKER THREAD)是指工作线程，在一台服务器上，可以有多个工作线程。因为每一个工作线程要耗费资源，所以，SQL Server有一个最大工作线程数。一个TASK(TASK是WORKER中运行最小的任务单元)进来，系统会给它分配一个工作线程进行处理，但是当所有的工作线程都在忙，而且已经达到了最大工作线程数，SQL Server就要等待，直到有一个忙的工作线程被释放，最大工作线程数可以通过下面的查询得到。SQL SERVER并不是一开始就把这些所有的工作线程都创建，而是依据需要而创建。

　　使用以下查询语句可以查询到当前最大工作线程数。

　　SELECT max_workers_count FROM sys.dm_os_sys_info

　　结果如图11-4所示。

　　图11-4 最大工作线程查询值

　　Windows使用抢占方式(pre-emptive)调度模型进行调度，意味着由调度程序决定运行某个任务的线程何时需要为另外一个任务让路并切换出去，这种方式可以很好的运行在很多同等重要的不同服务的服务器上，但对于运行SQL Server的服务器来说，这种方式并不理想，因为一个SQL Server任务可能随时被切换出去，而仅仅是为了给一个次要的Windows任务一些CPU的时间。SQL Server有着自身的调度程序，采用非抢占式或协作模型，它依赖于所有线程在必须等待某事件时能产生处理时间，对于SQL Server来说这种模型是一种高效的模型，因为它可以判断某个线程在何时需要处理器时间，即CPU时间。

　　TASK是由BATCH而来，一个连接，可以包含多个BATCH，而每个BATCH则可以分解成多个TASK，如下面某一个连接要做的事情，这个连接要做的有两个BATCH，而每个BATCH，如以下查询语句，可能会被分解成多个TASK，因为可以支持并行化查询。具体BATCH怎么分解成TASK，以及分解成多少个，则是由SQL Server内部进行处理。

• 　　INSERT INTO TABLE_B VALUES (‘aaa’)

• 　　GO

• 　　SELECT * FROM TABLE_B

• 　　GO

　　了解Connection、Batch、Task、Worker、Scheduler这些概念后，那么，它们之间的关系如何呢?具体的关系如图11-5所示。　　

　　图11-5 Batch、Task、Worker、Scheduler关系

　　客户端向服务器发送请求时，会先建立一个连接，建立的连接数受max/min connection两个参数的影响，每个连接有一个相应的SPID，只要用户没有退出，或者没有timeout，这个始终是存在的。

　　在每一个连接里，可能会有多个batch，在一个连接里，batch都是按顺序的，只有上一个batch执行完了，才会执行下面一个batch。因为有很多连接，所以从SQL Server层面上看，同时会有很多个batch并行进行。每一个batch，可能会分解成多个task以支持如并行查询，这样，在SQL层面上来看，同时会有很多个TASK。

　　SQL Server上，每一个CPU通常会对应一个Scheduler，有几个额外的系统Scheduler，只是用来执行一些系统任务，对用户来讲，只需要关心User Scheduler就可以了，如果有4个CPU的话，那么通常就会有4个User Scheduler。

　　每个Scheduler上，可以有多个worker对应，Worker是真正的执行单元，Scheduler(对CPU的封装)是执行的地方，Worker的总数受max worker_thread限制，每一个worker在创建的时候，自己需要申请2M内存空间，如果max worker_thread为1024，并且那些worker全部创建的话，至少需要2G空间，所以过多的worker，会占用很多系统资源。

　　在SQL Server中根据等待类型进行分类，通常可以分为三类：

• 　　Resource waits(资源等待)

　　当某个工作线程请求访问某个不可用的资源(因为该资源正在由其他某个工作线程使用，或者该资源尚不可用)时，便会发生资源等待。资源等待的示例包括锁等待、闩锁等待、网络等待以及磁盘 I/O 等待，锁等待和闩锁等待是指等待同步对象。

• 　　Queue waits(队列等待)

　　当工作线程空闲，等待分配工作时便会发生队列等待，队列等待通常发生在系统后台任务(如监视死锁以及清除已删除的记录等任务)中，这些任务将等待工作请求被放入工作队列，即使没有新数据包放入队列，队列等待也可能定期处于活动状态。

• 　　External waits(外部等待)

　　当 SQL Server 工作线程正在等待外部事件(如扩展存储过程调用或链接服务器查询)完成时，便会发生外部等待。当诊断有防碍的问题时，请记住，外部等待不会始终表示工作线程处于空闲状态，因为工作线程可能处于活动状态且正在运行某些外部代码。

　　资源等待，包括I/O、加锁以及内存，是最为常见的等待。

　　如果出现下列任一情况，则SQL Server 工作线程不可能处于等待状态：

• 　　资源变得可用。

• 　　查询非空。

• 　　外部进程完成。

　　尽管线程不再处于等待状态，但是它并不表示立即开始运行，因为此类线程首先放入可运行工作线程的队列中，并且必须等待量程在计划程序中运行，在SQL Server 2005中，等待时间计数器为bigint值。

　　使用以下查询语句可以查看等待类型，如图11-6所示。

　　select * from sys.dm_os_wait_stats　　

　　图11-6 等待类型

　　关于sys.dm_os_wait_stats字段说明，见表11-3。

　　表11-3 sys.dm_os_wait_stats表说明　　

　　关于等待类型说明，见表11-4。

　　表11-4 等待类型说明

　 本章节主要讲解了关于“LoadRunner性能测试—SQL等待类型”的内容，大家觉得有用的话记得没有来这里啦和小编一起学习涨薪技能哦。（笔芯）