你的位置:首页 > 数据库

[数据库]深入解析SQL Server并行执行原理及实践(下)


谈完并行执行的原理,咱们再来谈谈优化,到底并行执行能给我们带来哪些好处,我们又应该注意什么呢,下面展开.

 

Amdahl’s  Law

再谈并行优化前我想有必要谈谈阿姆达尔定律,可惜老爷子去年已经驾鹤先去了.

 

其中P:可以并行的百分比

N:算法并行计算使用的”CPU”

这里我们举个简单的例子,我们来做一份大餐,如图1-1所示

 

                                  图1-2

 

SQLServer中禁止并行的一些操作

上面我们了解了并行的操作性,但在SQL Server并不是所有操作都可以并行的,有些操作符会导致整个执行计划无法并行,而有些会使得某些分支(branch)无法并行,下面罗列出相关的操作符对并行的影响,这些感兴趣的朋友可以自行测试.

执行计划禁止并行

T-SQL scalar functions

更新表变量数据

访问系统表

动态游标

Branche不能并型

TOP(global)

2012以前窗口函数(Row_Number())

Multi -Statement  Function

Backward scan

CTE递归

 

并行执行的优点

说了一些限制,我们再来简单说下优点,要不开此文章的意义何在J.实际上在上半部分文章中大家可能已经感受到它的优点了,这里再简单总结下. 实际上在并行中

计算工作是均匀的分配在参与并行的threads中

所有的threads同时工作,无先后之分

某些操作中threads自身的工作完成后还会协助threads工作

虽然会有短暂的CXPACKET等待(数据分布,预估等问题)但基本可以解决或是缓解.

执行时分支(Branchs)间可以是无顺序的,更好的增加了并行.

针对CPU-Bound的操作,SQL Server可以说时随着CPU(并行度)的增加,性能也基本是线性增加的.

 

并行相关的设置

SQL Server中有并行相关的一些设置,主要有两个:并行阈值及最大并行度.

并行阈值:上篇已经提到过,查询子树大小触发并行的条件,此值的设定仁者见仁智者见智了,一般设定为实例执行计划编译的平均查询子树大小上下幅度不超过20%

最大并行度:查询中的操作符可同时采用的线程数.这个值便随着NUMA的诞生应尤为注意,早在SQL 2005研发阶段,NUMA开始出现,而SQL 2005也提供了支持,但程度有限,随着SQLOS的进一步演化在SQL2008时对其支持已经很不错了,这里有大家都知道的NUMA架构下的foreign memory问题,实际上SQL Server在采用并行时会试图将并行的线程都集中在某个NUMA节点下,所以我们在配置初始参数时并行度最好控制在某个NUMA节点的核数内,而且最好是偶数,这里面涉及到很多SQLOS的知识,限于篇幅就不深入了.

 

使用并行应注意的问题

强制使用并行

Trace flag 8649 在SQL Server中可以不触发并行而手动指定并行,注意这个标记是无官方文档记录,勿轻易使用.使用时只需在查询最好加上query hint:Option(querytraceon 8649)即可

数据分布不均,预估,碎片等问题

导致CXPACKET等待以及过多无谓IO,应对方式创建临时对象,更新统计信息,整理碎片等.

nested loop Join导致的随机IO,及nested loopjoin预读问题等

冷数据中使用并行nested join可能导致实例的IO稳定性受影响,面对具体场景应酌情使用.应对方式可以关闭nested loop预读,而nested loop预读时SQL Server也会试图将随机IO转化为连续IO,如具体应用合理应接受并行nested loop join.

线程饥饿问题(worker thread starvation)

前面我们说过,线程的授予是按照分支(branches)及并行度授予的,如果并行度高,此时复杂的查询下分支又很多,这个时候可能针对某个查询分配过多线程,加之这类查询又高并发,则这时出现线程饥饿的几率就大大增加了.具体生产中,这个应引起我们的注意.这里给大家举个简单的实例,感兴趣的同学可以自己测试下.这个查询有5个分支,分支所申请的线程就是5*16共80个!如图5-1

code

---- worker thread starvationselect a.productid,count_big(*) as rowsfrom dbo.bigproduct as ainner merge join dbo.bigtransactionhistory as bon a.productid=b.productidinner merge join dbo.bigproduct as con c.ProductID=b.ProductIDinner merge join dbo.bigTransactionHistory as don d.[ProductID]=c.ProductIDwhere a.ProductID between 1000 and 1020group by a.productidorder by a.productidoption(querytraceon 8649,maxdop 16)-------much join with many branches cost many threads

 

 code

set statistics time onselect   maxN=max(num.number)from dbo.numbers as numwhere   num.number<30000   and convert(integer,convert(varchar(max),num.number)) % 2=0option(Maxdop 3,-----5,7querytraceon 8649);

 

 

但当我将并行数调整为偶数时,执行时间居然长达数秒…打开trace profiler跟踪dead lock chain我们发现,当并行数为偶数时出现了死锁.

注我们用Trace profiler捕捉死锁

如图6-1,6-2,6-3

code
select    maxN=max(num.number)from dbo.numbers as numwhere    num.number<30000   and convert(integer,convert(varchar(max),num.number)) % 2=0option(Maxdop 4,-----2,6querytraceon 8649);

 

                              图6-2

 

                                图6-4

 

而反观并行采用奇数并行数,这时当分发数据时就不会造成某个thread所持有的数据只是奇数或是偶数,也就不会造成后来的情形,死锁也就不会出现.如图6-4感兴趣的同学可以做实验调整并行数并阅读相应的执行计划.

 

                                    7-1

 

可以看出我的这条语句由于对大量结果集进行排序,致使消耗了365MB的内存,并且由于分别对actualcost, quantity排序使得在进行第二个排序时内存不足并溢出,排序的操作只能在tempdb中进行.

Sort由于是典型的计算密集型运算符,此查询在我的机器上执行时间为5s

大量的内存被个别查询长时间独占,使得Buffer Pool的稳定性下降,进而可能影响整体吞吐.

关于SQL Server的Sort限于篇幅这里就不细说了.

在介绍”类MapReduce”之前,我想先接着上面Sort溢出的现象给大家简单介绍下通过Query hints 来影响优化器的资源分配

code

Declare@p1 int,@p2 nvarchar(56),@p3 smallint,@p4 int,@p5 bigint,@p6 bigint,@i intselect @i=3001; with p as(select productid,ProductNumber=convert(nvarchar(56),ProductNumber),reorderpointfrom bigproduct as bp)select@p1=p.productid,@p2=p.productnumber,@p3=p.reorderpoint,@p4=th.transactionid,@p5=rank()over (partition by p.productid        order by th.actualcost desc),@p6=rank()over (partition by p.productid        order by th.quantity desc)from bigproduct as pjoin bigtransactionhistory as th on th.productid=p.productidwhere p.productid between 1001 and @ioption(OPTIMIZE FOR (@i=5001))

 

 

通过查询可以看出由于我加了Query Hint,改变了优化器的资源评估标准,使得优化器认为productid本身需要资源从1001 and 3001分配变为了1001 and 5001分配,内存申请由365MB变为了685MB,接近一倍的增长,避免了溢出.并且执行时间也由5S变为了2S.提升了用户体验

如图7-2

 执行中输出实际执行计划可以看出,此计划中消耗的内存15MB,和上述的执行计划相比有指数级的下降,同时执行时间为不到2s,保证执行时间的同时明显降低了资源消耗,从而避免了实例级的影响.

已经很美好了:)

如图7-3

 code

select bp.productid,bp.productnumber,bp.reorderpointinto #pfrom bigproduct as bpwhere bp.productid between 1001 and 3001 alter table #p add primary key (productid) Declare@p1 int,@p2 nvarchar(56),@p3 smallint,@p4 int,@p5 bigint,@p6 bigintselect @p1=p.productid,@p2=p.productnumber,@p3=p.reorderpoint,@p4=ca.transactionid,@p5=ca.linetotalrank,@p6=ca.orderqtyrankfrom #p as pcross apply(select th.transactionid,linetotalrank=rank()over(order by th.actualcost desc),orderqtyrank=rank() over(order by th.quantity desc)from bigtransactionhistory as thwhere th.productid=p.productid) as ca drop table #p

 

通过查询时输出执行计划 如图7-4所示

我们可以看到通过将外表数据放入临时表中,使得内存消耗进一步降低,而数据较为平均的分布到多个threads中,你可能看到其中不少threads是没有数据的,其实有时需要我们根据查询管控并行度的.而在执行时间上有可能得到进一步的改善!

 

                    图7-5

 

至此这个优化更合理的解决了面临的问题!

我们的并行原理及实践也到此为止吧.

说点体外话,不少朋友认为SQL Server是小儿科,没内容,技术含量不高,而且在国内的互联网公司中又显得格格不入.这种想法真心Too Naïve.这里我可以告诉大家,SQL Server,乃至关系型数据库的水很深. 如果你是相关的从业者,全身心的投入进来吧,其实很好玩.

更多Inside SQL Server请关注

微信公众号InsideSQLServer及我的新浪微博@shanksgao

认为有帮助的同学请点赞!