基于SQL Server OS的任务调度机制详解

简介

     sql server os是在windows之上，用于服务sql server的一个用户级别的操作系统层次。它将操作系统部分的功能从整个sql server引擎中抽象出来，单独形成一层，以便为存储引擎提供服务。sql server os主要提供了任务调度、内存分配、死锁检测、资源检测、锁管理、buffer pool管理等多种功能。本篇文章主要是谈一谈sql os中所提供的任务调度机制。

抢占式(preemptive)调度与非抢占式(non-preemptive)调度

    数据库层面的任务调度的起源是acm上的一篇名为“operating system support for database management”。但是对于windows来说，在操作系统层面专门加入支持数据库的任务调度，还不如在sql server中专门抽象出来一层进行调度，既然可以抽象出来一层进行数据库层面的任务调度，那么何不在这个抽象层进行内存和io等的管理呢？这个想法，就是sql server os的起源。

    在windows nt4之后，windows任务调度是抢占式的，也就是说windows任务是根据任务的优先级和时间片来决定。如果一个任务的时间片用完，或是有更高优先级的任务正在等待，那么操作系统可以强制剥夺正在运行的线程（线程是任务调度的基本单位）所占用的cpu，将cpu资源让给其它线程。

    但是对于sql server来说，这种非合作式的、基于时间片的任务调度机制就不那么合适了。如果sql server使用windows内的任务调度机制来进行任务调度的话，windows不会根据sql server的调度机制进行优化，只是根据时间片和优先级来中断线程，这会导致如下两个缺陷:

windows不会知道sql server中任务(也就是sql os中的task,会在文章后面讲到)的最佳中断点，这势必会造成更多的context switch（context switch代价非常非常高昂,需要线程字用户态和核心态之间转换），因为windows调度不是线程本身决定是否该出让cpu，而是由windows决定。windows并不会知道当前数据库中对应的线程是否正在做关键任务，只会不分青红皂白的夺取线程的cpu。 连入sql server的连接不可能一直在执行，每一个batch之间会有大量空闲时间。如果每个连接都需要单独占用一个线程，那么sql server维护这些线程就需要消耗额外的资源，这是很不明智的。

     而对于sql server os来说，线程调度采用的合作模式而不是抢占模式。这是因为这些数据库内的任务都在sql server这个sandbox之内，sql server充分相信其内线程，所以除非线程主动放弃cpu，sql server os不会强制剥夺线程的cpu。这样一来，虽然worker之间的切换依然是通过windows的context switch进行，但这种合作模式会大大减少所需context switch的次数。

    sql server决定哪一个时间点哪一个线程运行，是通过一个叫scheduler的东西进行的，下面让我们来看scheduler。

scheduler

    sql server中每一个逻辑cpu都有一个与之对应的scheduler，只有拿到scheduler所有权的任务才允许被执行，scheduler可以看做一个队sqlos来说的逻辑cpu。您可以通过sys.dm_os_schedulers这个dmv来看系统中所有的scheduler，如图1所示。
 

    图1.查看sys.dm_os_schedulers

   我的笔记本是一个i7四核8线程的cpu，对应的，可以看到除了dac和运行系统任务的hidden scheduler，剩下的scheduler一共8个，每个对应一个逻辑cpu，用于处理内部task。当然，您也可以通过设置affinity来将某些scheduler offline，如图2所示。注意，这个过程是在线的，无需重启sql server就能实现。

    图2.设置affinity

    此时，无需重启实例就能看到4个scheduler被offline,如图3所示:
 

    图3.在线offline 4个scheduler

    一般来说，除非您的服务器上运行其他实例或程序，否则不需要控制affinity。

    在图1中，我们还注意到，除了visible的scheduler之外，还有一些特殊的scheduler，这些scheduler的id都大于255，这类scheduler都用于系统内部使用，比如说资源管理、dac、备份还原操作等。另外，虽然scheduler和逻辑cpu的个数一致，但这并不意味着scheduler和固定的逻辑cpu相绑定，而是scheduler可以在任何cpu上运行，只有您设置了affinity mask之后，scheduler才会被固定在某个cpu上。这样的一个好处是，当一个scheduler非常繁忙时，可能不会导致只有一个物理cpu繁忙，因为scheduler会在多个cpu之间移动，从而使得cpu的使用倾向于平均。

    这意味着对于一个比较长的查询，可以前半部分在cpu0上执行，而后半部分在cpu1上执行。

    另外，在每一个scheduler上，同一时间只能有一个worker运行，所有的资源都就绪但没有拿到scheduler，那么这个worker就处于runnable状态。下面让我们来看一看worker。

worker

    每一个worker可以看做是对应一个线程（或纤程），scheduler不会直接调度线程，而是调度worker。worker会随着负载的增加而增加，换句话说，worker是按需增加，直到增加到最大数字。在sql server中，默认的worker最大数是由sql server进行管理的。根据32位还是64位，以及cpu的数量来设置最大worker,具体的计算公式，您可以参阅bol：。当然您也可以设置最大worker数量，如图4所示。

   

    图4.设置最大worker数量  

    如果是自动配置，那么sql server的最大工作线程数量可以在sys.dm_os_sys_info中看到，如图5所示。

     

     图5.查看自动配置的最大worker数量

    一般来说，这个值您都无需进行设置，但也有一些情况，需要设置这个值。那就是worker线程用尽，此时除了dac之外，您甚至无法连入sql server。

    worker实际上会对应windows上的一个线程，并与某个特定scheduler绑定，每一个worker只要开始执行task,除非task完成，否则worker永远不会放弃这个task,如果一个task在运行过程由于锁、io等陷入等待，那么实际上worker就会陷入等待。

    此外，同一个连接内的多个batch之间倾向于使用同一个worker,比如第一个batch使用了worker 100,那么第二个batch也同样倾向于是用worker 100，但这并不绝对。

    正在运行的任务所是用的worker，我们可以通过dmv sys.dm_exec_requests查看正在运行的任务，其中的task_address列可以看到正在运行的task,再通过sys.dm_os_tasks的worker_address来查看对应的worker。

    sql server会为每一个worker保留大约2m左右的内存，对于每一个scheduler上所能有的worker数量是服务器的最大worker数量/在线的scheduler,每一个scheduler所绑定的worker会形成worker池，这意味着每一个scheduler需要worker时，首先在worker池中中查找空闲的worker，如果没有空闲的worker时，才会创建新的worker。这个行为会和连接池类似。

    那么当一个scheduler空闲超过15分钟，或是windows面临内存压力时。sql server就会尝试trim这个worker池来释放被worker所占用的内存。

task

    task是worker上运行的最小任务单元。只能拿到worker的task才能够运行。我们可以看下面一个简单的例子，如代码1所示。

select @@version goselect @@spid go

    代码1.一个连接上的两个batch

    代码1中的两个batch属于一个连接，每一个batch中都是一个简单的task,如我们前面所说，这两个task更倾向于复用同一个worker，因为他们属于同一个连接。但也有可能，这两个task使用了不同的worker,甚至是不同的scheduler。

    除了用户所用的task之外，还有一些永久的系统task，这类task会永远占据worker,这些task包括死锁检测、lazy writer等。

task在scheduler上的平均分配

    新的task还会尝试在scheduler之间平均分配，可以通过sys.dm_os_schedulers来看到一个load_factor列，这列的值就是用于供task向scheduler进行分配时，用来参考。

    每次一个新的task进入node时，会选择负载最少的的scheduler。但是，如果每次都来做一次选择，那么就会在task入队时造成瓶颈(这个瓶颈类似于tempdb sgam页争抢)。因此sql os对于每一个连接，都会记住上次运行的scheduler id，在新的task进入时作为提示(hint)。但如果一个scheduler的负载大于所有scheduler平均值的20%，则会忽略这个提示。负载可以通过上面提到的load_factor列来看，对于某个task运行的时间比较长，则很有可能造成scheduler上task分配的不均匀。

worker的yield

    由于sql server是非抢占式调度，那么就不能为了完成某个task，让worker占据scheduler一直运行。如果是这样，那么处于runnable的worker将会饥饿，这不利于大量并发，也违背了sql os调度的初衷。

    因此，在合适的时间点让出scheduler就是关键。worker让出cpu使得其它worker可以运行的过程称之为yield。yield大体可分为两种，一种是所谓的“natural yield”,这种方式是worker在运行过程中被锁或是某些资源阻塞，此时，该worker就会让出scheduler来让其它worker运行。另外一种情况是worker没有遇到阻塞，但在时间片到了之后，主动让出scheduler,这就是所谓的“voluntarily yield”，这也就是sos_scheduler_yield等待类型的由来，一个worker由running状态转到waiting状态的过程被称之为switching。sql os的一个基本思想就是，要多进行switching，来保证高并发。下面我们来看几种常见的yield场景:

基于时间片的voluntarily yield大概使得worker每4秒yield一次。这个值可以通过sys.dm_os_schedulers的quantum_length_us列看到。

每64k结果集排序，就做一次yield。

语句complie,会做yield。

读取数据页时

batch中每一句话做完，就会做一次yield。

如果客户端不能及时取走数据，worker也会做yield。

sql server os中的抢占式任务调度
    对于一些代码来说，sql server会存在一些抢占式代码。如果您在等待类型中看到“preemptive_*”类型的等待，说明这里面的代码正在运行在抢占式任务调度模式。这类任务包括扩展存储过程、调用windows api、日志增长（日志填0）。我们知道，合作式的任务调度需要任务本身yield，但这类代码在sql server 之外，如果让他们运行在合作式任务调度这个sandbox之内，这类代码如果不yield，则会永远占用scheduler。这是非常危险的。

    因此，在进入抢占式模式之前，首先需要将scheduler的控制权交给在runable队列中的下一个worker。此时，抢占式模式运行的代码不再由sql os控制，转而由windows任务调度系统控制。因此一个task的生命周期如果再加上转到抢占式任务调度模式，则会如图6所示。

  
 图6.一个task完整的生命周期

每一个scheduler的任务调度

    对于每一个scheduler的调度，一个简单的模型如图7所示。   

图7.一个scheduler的调度周期模型

小结
    sql server os在windows之上抽象出一套非抢占式的任务调度机制，从而减少了context switch。同时，又有一套线程自己的yield机制，相比windows随机抢占数据库之内的线程而言，让线程自己来yield则会大量减少context switch,从而提升了并发性。