sql server 2012 数据引擎任务调度算法解析(上)

微软在sql server 2012版本之后,引入了新的任务调度算法,这个算法与之前的版本有一些细微的差别。我在这里试着简单描述一下,一些基本概念就不再赘述了,比如NUMA、scheduler、worker什么的,这些内容在网上一搜一大把,如果不了解随便看几篇文章大概也就有所了解了。

让我们从最基本的内容开始:

在sql server 2012版本以前,整个任务的调度是在一个新的连接到达数据库引擎开始的。当新的连接到达后会以轮循的方式在与连接端口绑定的某一NUMA节点上指派一个scheduler(注1) ,之后,这个新的连接会分配给当前节点负载系数最小的一个scheduler,负载系数大致等于分配给scheduler的任务数,需要注意的是这个负载系数与当前节点上的CPU使用率无关

(我们可以通过select scheduler_id,current_tasks_count from sys.dm_os_schedulers 查看scheduler上的当前任务数)

在给连接分配了一个scheduler后,只要这个连接没有断开,分配的scheduler就与这个连接保持着分配关系,即成为了这个连接的首选scheduler。当客户端提交一个命令后,如batch,rpc等,sqlos也会为这个任务指定一个scheduler,并且保持到命令执行完毕。

在为任务分配scheduler时候,sqlos会优先选择当前连接的首选scheduler,但如果连接的首选scheduler负载系数比最低负载scheduler高出20%,那么sqlos会将这个任务分配给同一NUMA节点下的负载系统最小的scheduler

我们来画个图表示一下,假设默认端口1433只绑定了NUMA节点0

 

连接以及任务分配流程:

  1. 新连接到达后,会按与端口绑定的NUMA进行轮循选择节点,但我们只绑定了NUMA 0,所以也没什么好选的了
  2. 在连接到达NUMA 0后,sqlos会把此新连接分配到负载系数最小(10)的sche0上。
  3. 此连接客户端发出命令,sqlos发现sche0为首选sheduler,且负载系数正常,则直接使用sche0进行任务指派,且负载系数+1=11
  4. 此时,sche1上的一个空闲连接发出了新的命令,sqlos先判断sche1为这个连接的首选scheduler,但是由于sche1的负载为14,sche0为11,计算14/11= 1.272727,即首选sche1负载已经高于sche0 20%以上,所以sqlos将在sche0上进行任务指派,sche0负载+1,sche1负载不变(注意此连接的首选scheduler没有变,还是sche1,在命令执行完毕后,如果再发出新的命令,还是要再次重复流程4)

 

以上即是sql server 2012版本以前(包括2012)的基本任务调度算法……可是等一等,不是说2012的算法改了吗,怎么还包括2012??

这里要说明的是:只有sql server 2012 Enterprise Edition使用了新的算法,其它版本的调度流程没有变,还是同上面写的一致

 

新连接到达后,一直到给连接指派scheduler都是与之前的流程一致,没有变化,主要变化是在给连接指定了scheduler后,连接发出一个新的命令,sqlos给任务指派scheduler的算法有小小的改变,那么具体的改变是什么呢??

且听下回……分解

 

注1:为什么说是与端口绑定的NUMA

因为通过tcp端口的建立连接是可以通过设置NUMA掩码的方式进行NUMA绑定,这样可以更合理的分配cpu的使用

假设我们有一个4NUMA节点的数据库实例,节点的编号分别为3210。此实例上面跑了两条不同的业务线,一个业务线的优先级比较高,比如面向前端用户的OLTP业务;另一个业务线是需要大量计算资源的OLAP后台业务,但是OLAP的业务线对于结果的返回不需要实时性(当然很少OLTPOLAP业务都使用一个服务器),那么我们可以让OLAP业务只使用一个NUMA节点,各种计算就让它慢慢在哪算,不要占用过多的CPU资源;OLTP分配三个NUMA,保证前台用户的访问有足够资源,那么掩码的设置可以这样:

 

那我们在配置管理器中设置sql server的侦听端口为下图,重启服务就可以了

 


      

 

 

posted @ 2015-07-02 16:24  活力大疯子  阅读(...)  评论(... 编辑 收藏