今天配合客户做压力测试，我对数据库进行跟踪，存在一些疑问，请达人指点。一些简单的查询或存储过程（单独执行时间少于1S），被SQL SERVER 设定为并发，在进程列表中的表现就是一个查询的执行开了10+线程，第一个等待状态为CXPACKET，其余都是suspended。第一个线程block其余的线程。cost threshold for parallelism 是默认设定 5S.理论上应该是the estimated cost 高于5S才应该安排并发吧？莫非SQL SERVER 开销评估出现误差？
解决方案 »
- 未能加载包 Microsoft SQl server object explorer
- 关于MSSQL里面字符转换格式的问题
- 关于查询
- 求库存?大家帮帮忙!
- 求高手解答：HQL排序问题？
- 请你进来看看这个SQL如何写？先谢了。
- exec (N'Select '+ @RecordCount +'= Count(*) From ' + @tableName)
- 请教各位大虾，关于排名的问题，急。。（在线等待）谢。同时散分。
- sql数据库数据恢复
- ?sql server 2008 如何导入tdms格式的数据?
- 求一个3表的联合查询语句，哦不，是2表联合查询
- sql server 怎么把存储过程的执行结构放到txt中？
探讨一下哈，兄台。
数据库活动进程中出现大批量的suspended线程和blocking，让我胆战心惊啊，不过还好都没有形成死锁。
在某些情况下，即使查询的开销计划小于当前 cost threshold for parallelism 的值，也有可能选择并行计划。出现这种情况，是因为使用并行还是串行计划是根据完成完全优化之前所提供的开销估计确定的。可以配合max degree of parallelism 选项.这样能最大限制的控制并行导致cpu不可用而造成的短查询的等待。如：sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism', 4;--假如是8个(核)cpu
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'cost threshold for parallelism', 10;--将此时间增加
GO
RECONFIGURE WITH OVERRIDE;
GO
如果有，也可以单独指定option(maxdop 1)来限制.
cost 的单位不是Sec啦，有固定的计算公式. 单独执行小於1s的SQL,其cost不一定就小於5.
联机帮助中说单位是秒啊？使用 cost threshold for parallelism 选项指定 Microsoft SQL Server 创建和运行并行查询计划的阈值。仅当运行同一查询的串行计划的估计开销高于在 cost threshold for parallelism 中设置的值时，SQL Server 才创建和运行该查询的并行计划。开销指的是在特定硬件配置中运行串行计划估计需要花费的时间（秒）。只能在对称多处理器系统上设置 cost threshold for parallelism。并行计划对需时较长的查询通常更加有益；其性能优势将抵消初始化、同步和终止并行计划所需的额外时间开销。短时间和长时间查询混合运行时，可以灵活使用 cost threshold for parallelism 选项。短时间查询使用串行计划运行，而长时间查询使用并行计划运行。cost threshold for parallelism 的值确定哪些查询是短时间查询，因而应该使用串行计划运行。在某些情况下，即使查询的开销计划小于当前 cost threshold for parallelism 的值，也有可能选择并行计划。出现这种情况，是因为使用并行还是串行计划是根据完成完全优化之前所提供的开销估计确定的。cost threshold for parallelism 选项可设置为 0 到 32767 之间的任何值。默认值为 5。在下列情况下，SQL Server 将忽略 cost threshold for parallelism 的值：计算机只有一个处理器。
由于 affinity mask 配置选项的限制，SQL Server 只能使用一个 CPU。
max degree of parallelism 选项设置为 1。
cost threshold for parallelism 选项是一个高级选项。如果使用 sp_configure 系统存储过程来更改此设置，则只有在 show advanced options 设置为 1 时才能更改 cost threshold for parallelism。更改后的设置将立即生效，而不需要重新启动服务器。示例
以下示例将 cost threshold for parallelism 设置为 10 秒。sp_configure 'show advanced options', 1;GO
reconfigure;GO
sp_configure 'cost threshold for parallelism', 10;GO
reconfigure;GO
是Web压力测试是发生的事情，看来我还要在排查一下跟踪数据中CPU开销较大的查询了，不过CPU并行度设的低了，也会影响其他真正需要并行的查询，这个貌似不太好判断啊。
是的，所以要根据你的查询来设置一个平衡点，经验值是cpu-1.之前我的一台服务器上只有一个查询一执行cpu就会100%，该查询每次耗时是3s.
其它都是非耗时查询.
这种情况下，我将并行度设置为cpu数/2. 修改之后和之前的对前，cpu基本没再出现100%,而且其它查询也未受影响(因为他们本来就很快，基本不需要全部cpu并行).
那你这个查询的执行时间是否变成6秒了？其实我觉得短时间CPU100%也不是什么大问题，充分利用硬件也好。对于我的问题，我觉得根源不在于我CPU并行度的多少，而在于SQL SERVER为什么把简单的查询设为并行查询了，即使我调低了并行度，不见得去就会取消小查询的并行计划，除非我设成1。
refer this
http://msdn.microsoft.com/en-us/library/cc966425.aspx"Costs associated with query plans and execution contexts"
对于19层的疑问，我改后3s的依然还是3s，因为我说的3s全部都是指数据已缓存.
因为你的CPU并行度降低，所以永远不会出现CPU100%的情况，如果有其他大的并行查询需要用多个线程来运算，效率岂不是降低了？
1.
此cost非彼cost，Costs associated with query plans and execution contexts指的是编译这个查询的开
销，它影响了查询计划在plan cache里呆的时间。cost threshold for parallelism 里定义的cost是完成
查询所需要的开销。例如:一个Ad-hoc查询的编译成本是0，但这个查询却可以是并行执行的。2.
并行计划出现CXPACKET等待是很正常的，也是无法避免的。你要确定的是它是否
成为影响系统性能和吞吐量的主要原因。可以在测试开始和结束分别抓取相关的
统计进行分析，再做出判断。一般是调整MAXDOP,调整cost threshold for parallelism
场景较少，这样的调整通常需要反复测试，最终确定一个比较合适的值。
从跟踪情况来看，应该是以逻辑CPU来计算的。例如：4X4的CPU，当CPU并行度设为0时，一个查询的最大并行线程数应该是16个。
1.暂时从联机文档看，应该是所指不同。
2.并行计划是正常的，但出现CXPACKET等待占的比率很大时，就不能说也是正常了.
就我遇到的一引起情况来看，当一个耗时的查询在执行时，并行计划会造成全部cpu100%，这导致很多查询被挂起来等待cpu的资源。
个人认为一方面需要优化这些sql,另一方面可以找一个平衡点，来设置并发。 将max degree of parallelism设置为cpu数量-1或-2，个人认为值得测试.
修改后一段时间后，对比与之前的基线，看是否会影响性能。
是的，一些查询随着DOP的增加，性能是不升反降的。更有甚者会影响整个系统的稳定和性能。
这样的查询通常是需要特别照顾的。2.
补充一点：Ad-hoc查询被缓存时，它的编译成本被指定为0，这样做的好处是当出现内存压力时，
这些计划是被清除出缓存的首选对象。而当这个计划被重用后，它的编译成本将被重置成它最初编译的成本。
我是4X4的CPU，同一个Spid线程数远远超过4个。
大数据量表扫描时通常都会并发，这也正常，所以并行度设定为cpu-1也是必要的。问题是查询速度非常快的Spid，却产生了大量的并发。这个会不会跟压力测试本身有关？因为是模拟数百用户同时登录进行操作，可能同时执行相同的查询。
SQL Server的一切，尽在微软BI开拓者www.windbi.com
我在16核(2*8核)上测试的结果是指cpu核数量，不是物理cpu.
你是怎么测的？需要在一个没有任何压力的情况测试.我刚测的，如果并行指为4,cpu4个核起作用，设置为8，cpu8个核起作用。
这个从任务管理器上的cpu视图可以明显看出来。我是win2k8 x64 企业版 + sql2k8标准版sp1.
你设的是SQL SERVER的嘛？如果任务管理器上的cpu视图中CPU个数发生变化，你应该是在操作系统中禁用了部分C逻辑CPU。这两个概念不同吧？
呵呵，我更改了一下max degree of parallelism，事实上任务管理器中逻辑CPU数目并没有发生变化。
这两个应该不是同一个东西。有图有真相（求教这里如何上传图片？）你是不是设定了Boot.ini高级选项的参数/Numproc？这个参数是配置多少个逻辑CPU可用的。
没有加/Numproc . 我不只在一台服务器上做过测试了。而且在生产环境也有已配置过的server.
CXPACKET:这种等待类型意味着任务在等待并执行的同步，并且经常成为“所有处理器运行在100%”的场景的原因。在一个OLTP系统中应当不会看到这种等待类型，除非正在进行一个在的索引重建。Microsoft的一般建义是将Max Degree of parallelism设置为等于物理处理器数目，以避免使用率100%的场景。我记得在一个微软的mvp的经验值是cpu总核数-1.我在实际应用中，2*4核，在cpu平均压力为40%时，设置为cpu/2时运行良好，不但改变了原来经常cpu 100%的现象，也未出现性能基线变的现象，而设置为6或7时，仍然会有100%现象出现。而cost threshold for parallelism似乎没有 Max Degree of parallelism那样有效果。所以这个参数还是要在实际环境中取一个平衡。
一方面在cpu高时，及时抓到这些sql,另外通过DMV来找到耗时的sql.随时改变这个参数值(不需要重启sql)，随时观察修改前后的性能基线。
如果这个参数是以物理CPU数目为准，减少 Max Degree of parallelism，那么在多核CPU中，4X4岂不是要比8X2浪费？
8个cpu设置为4,我目前是这么用的。
原因是：If there is a missing an index for a predicate that results in a table scan.
因为我有一个like的t-sql.至于他说的小于6cpu，设置成1,对于专家的说法，只能找机会试试了，现在手头的4cpu的，cpu占用都不过30%.
CPU占用不超过30%不代表没有CXPACKET，你可以观察一下。
wait_type wait_time_ms %
CXPACKET 60803 2.46
CXPACKET 65070 2.63
CXPACKET 19453 0.74
CXPACKET 25752 1.06
CXPACKET 63750 2.57
CXPACKET 13727 0.57
CXPACKET 18087 0.75
CXPACKET 60074 2.44
CXPACKET 13714 0.57
CXPACKET 13965 0.58
权衡利弊，感觉还是设为1可能比较好。
在OLAP数据处理时，主动把Max Degree of parallelism设为0，处理完以后再改为1.多次测试，也没有一个准确的结果。
后来并行改为2cpu.现在是53%.这台server全天cpu都>80%在跑各种各样的报表。再过一周观察下，再改成1看情况.不过cost threshold for parallelism这个值，似乎没有什么效果。
貌似MS不推荐修改cost threshold for parallelism的值。
你这个50%什么意思？状态为CXPACKET的线程数目百分比？
意思是在所有的等待中，cxpacket等待的时间比率.
我用的这个：SELECT TOP 50
[Wait type] = wait_type,
[Total_Wait time (s)] = wait_time_ms / 1000,
[Max_Wait_time (s)] = max_wait_time_ms /1000,
[% waiting] = CONVERT(DECIMAL(12,2), wait_time_ms * 100.0
/ SUM(wait_time_ms) OVER())
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
ORDER BY wait_time_ms DESC;
能不能讲一下你的OLAP数据库中常用的表是什么数量级，谢谢。