当前位置:Gxlcms > mysql > SQLServerOS的任务调度机制

SQLServerOS的任务调度机制

时间:2021-07-01 10:21:17 帮助过:52人阅读

简介 SQL Server OS是在Windows之上,用于服务SQL Server的一个用户级别的操作系统层次。它将操作系统部分的功能从整个SQL Server引擎中抽象出来,单独形成一层,以便为存储引擎提供服务。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

        图1.查看sys.dm_os_schedulers

     

       我的笔记本是一个i7四核8线程的CPU,对应的,可以看到除了DAC和运行系统任务的HIDDEN Scheduler,剩下的Scheduler一共8个,每个对应一个逻辑CPU,用于处理内部Task。当然,香港空间,您也可以通过设置Affinity来将某些Scheduler Offline,如图2所示。注意,这个过程是在线的,网站空间,无需重启SQL Server就能实现。

       

    2

        图2.设置Affinity

     

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

       

    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:(v=sql.105).aspx。当然您也可以设置最大Worker数量,如图4所示。

       

    4

        图4.设置最大Worker数量

       

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

         

    5

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

     

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

    人气教程排行