关于 CXPACKET,该如何处理

关于 CXPACKET
今天配合客户做压力测试，我对数据库进行跟踪，存在一些疑问，请达人指点。

一些简单的查询或存储过程（单独执行时间少于1S），被SQL SERVER 设定为并发，在进程列表中的表现就是一个查询的执行开了10+线程，第一个等待状态为CXPACKET，其余都是suspended。第一个线程block其余的线程。

cost threshold for parallelism 是默认设定 5S.

理论上应该是the estimated cost 高于5S才应该安排并发吧？莫非SQL SERVER 开销评估出现误差？

[解决办法]
我是来学习的
[解决办法]
我是进来蹭分的
[解决办法]

探讨

引用:
我是来学习的


探讨一下哈，兄台。


数据库活动进程中出现大批量的suspended线程和blocking，让我胆战心惊啊，不过还好都没有形成死锁。

[解决办法]
这个只能学习
[解决办法]
.
[解决办法]

[解决办法]
估计的执行计划在5S内 是作为串行的
[解决办法]
可以看下MSDN
[解决办法]
联机文档：
在某些情况下，即使查询的开销计划小于当前 cost threshold for parallelism 的值，也有可能选择并行计划。出现这种情况，是因为使用并行还是串行计划是根据完成完全优化之前所提供的开销估计确定的。

可以配合max degree of parallelism 选项.这样能最大限制的控制并行导致cpu不可用而造成的短查询的等待。如：

SQL code

sp_configure 'show advanced options', 1;GORECONFIGURE WITH OVERRIDE;GOsp_configure 'max degree of parallelism', 4;--假如是8个(核)cpuGORECONFIGURE WITH OVERRIDE;GOsp_configure 'show advanced options', 1;GORECONFIGURE WITH OVERRIDE;GOsp_configure 'cost threshold for parallelism', 10;--将此时间增加GORECONFIGURE WITH OVERRIDE;GO
[解决办法]
学习美美
[解决办法]
不过，造成cxpaket等待，大都是的确有耗时的sql执行，还是需要确定一下是否有这样的报表名job ?
如果有，也可以单独指定option(maxdop 1)来限制.
[解决办法]
学习

[解决办法]
学习.
[解决办法]
探讨

今天配合客户做压力测试，我对数据库进行跟踪，存在一些疑问，请达人指点。

  一些简单的查询或存储过程（单独执行时间少于1S），被SQL SERVER  设定为并发，在进程列表中的表现就是一个查询的执行开了10+线程，第一个等待状态为CXPACKET，其余都是suspended。第一个线程block其余的线程。

  cost threshold for parallelism 是默认设定 5S.

  理论上应该是the estimated cost 高于5S才应该安排并发吧？莫非SQL SERVER 开销评估出现误差？

[解决办法]
探讨

引用:
 不过，造成cxpaket等待，大都是的确有耗时的sql执行，还是需要确定一下是否有这样的报表名job ?
 如果有，也可以单独指定option(maxdop 1)来限制.


 是Web压力测试是发生的事情，看来我还要在排查一下跟踪数据中CPU开销较大的查询了，不过CPU并行度设的低了，也会影响其他真正需要并行的查询，这个貌似不太好判断啊。

[解决办法]
探讨

引用:
 引用:
 今天配合客户做压力测试，我对数据库进行跟踪，存在一些疑问，请达人指点。

 一些简单的查询或存储过程（单独执行时间少于1S），被SQL SERVER  设定为并发，在进程列表中的表现就是一个查询的执行开了10+线程，第一个等待状态为CXPACKET，其余都是suspended。第一个线程block其余的线程。

 cost threshold for parallelism 是默认设定 5S.

 理论上应该是the estimated cost 高于5S才应该安排并发吧？莫非SQL SERVER 开销评估出现误差？


 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



[解决办法]
一般微软的文档在介绍开销都是没有介绍单位的，但联机文档在介绍cost threshold for parallelism时，明确说单位是seconds，这个我也搞不懂了。
对于19层的疑问，我改后3s的依然还是3s，因为我说的3s全部都是指数据已缓存.
[解决办法]
关注
[解决办法]
学习
[解决办法]
关注一下~~
[解决办法]
探讨

引用:
 引用:
  引用:
  今天配合客户做压力测试，我对数据库进行跟踪，存在一些疑问，请达人指点。

  一些简单的查询或存储过程（单独执行时间少于1S），被SQL SERVER  设定为并发，在进程列表中的表现就是一个查询的执行开了10+线程，第一个等待状态为CXPACKET，其余都是suspended。第一个线程block其余的线程。

  cost threshold for parallelism 是默认设定 5S.

 refer this
http://msdn.microsoft.com/en-us/library/cc966425.aspx

 "Costs associated with query plans and execution contexts"

[解决办法]
能不能把你的数据库发给我看看？我的邮箱：v-gameng@microsoft.com. 发个邮件给我，我发个link给你上传。
[解决办法]
标红，欢迎讨论
[解决办法]
我是来学习的
[解决办法]
我是来学习的
[解决办法]
哦是学习的
[解决办法]
jf
[解决办法]
up
[解决办法]
学习
[解决办法]
探讨

联机文档：
在某些情况下，即使查询的开销计划小于当前 cost threshold for parallelism 的值，也有可能选择并行计划。出现这种情况，是因为使用并行还是串行计划是根据完成完全优化之前所提供的开销估计确定的。

可以配合max degree of parallelism 选项.这样能最大限制的控制并行导致cpu不可用而造成的短查询的等待。如：
SQL code
sp_configure'show advanced options',1;GORECONFIGUREWITH OVERRIDE;GO
sp_configure'max degree of parallelism',4;--假如是8个(核)cpuGORECONFIGUREWITH OVERRIDE;GO
sp_configure'show advanced options',1;GORECONFIGUREWITH OVERRIDE;GO
sp_configure'cost threshold for parallelism',10;--将此时间增加GORECONFIGUREWITH OVERRIDE;GO

[解决办法]
探讨
 
 
引用:
 引用:
  引用:
   引用:
   今天配合客户做压力测试，我对数据库进行跟踪，存在一些疑问，请达人指点。

   一些简单的查询或存储过程（单独执行时间少于1S），被SQL SERVER  设定为并发，在进程列表中的表现就是一个查询的执行开了10+线程，第一个等待状态为CXPACKET，其余都是suspended。第一个线程block其余的线程。

   cost threshold for parallelism 是默认设定 5S.

  refer this
 http://msdn.microsoft.com/en-us/library/cc966425.aspx

  "Costs associated with query plans and execution contexts"


 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并行度的判断，是应该按照物理CPU个数还是逻辑CPU个数？
 从跟踪情况来看，应该是以逻辑CPU来计算的。例如：4X4的CPU，当CPU并行度设为0时，一个查询的最大并行线程数应该是16个。

[解决办法]
学习。
[解决办法]
1.
是的，一些查询随着DOP的增加，性能是不升反降的。更有甚者会影响整个系统的稳定和性能。
这样的查询通常是需要特别照顾的。

2.
补充一点：Ad-hoc查询被缓存时，它的编译成本被指定为0，这样做的好处是当出现内存压力时，
这些计划是被清除出缓存的首选对象。而当这个计划被重用后，它的编译成本将被重置成它最初编译的成本。

[解决办法]
即是说查询执行的COST单位是sec? 这个跟CPU Time的统计又是有出入的. 照这个说法, 应该 Cost<= CPU elapsed Time, 但往往实际情况是相反的。


[解决办法]
asd
[解决办法]
是的，有CXPACKET等待是应该正常的。

但是，可以并行执行的运算就那么几个，实际应用中，通常是发生在scan时需要parallel.

所以出现大量CXPACKET时，个人觉得需要去检查相关的index是否合理咯.
[解决办法]
 the CXPACKET wait type is just an indication of coordination among parallel operators, that’s all. It in itself is not a wait on a resource. It is a “synchronization” wait. If you see the wait time for this as “high” it simply means that you have:

a) Parallel queries running on your server

c) Parallel queries that may be taking longer than you expect

The key here is a) Do you expect parallel queries? b) If not, you perhaps need some query tuning c) If so, go investigate one of these with high wait times for CXPACKET and find out what the tasks with the same session_id look like that DON’T have this wait type. If they are RUNNING then you simply have a query that just takes a long time (with perhaps a non-optimal plan). If the other task has a wait type of something like ASYNC_NETWORK_IO you have a problem with processing results from the client that could be slowing down the overall query. In either case,  the appearance of a parallel query may be a sign of possible tuning opportunities on your system.

---------------------------------------
SQL Server的一切，尽在微软BI开拓者www.windbi.com
[解决办法]
探讨

引用:
 引用:
 关于多核CPU并行度的判断，是应该按照物理CPU个数还是逻辑CPU个数？
 从跟踪情况来看，应该是以逻辑CPU来计算的。例如：4X4的CPU，当CPU并行度设为0时，一个查询的最大并行线程数应该是16个。


 按我测的来看是核，而且还存在设置为4,多数情况下会是5或6.
 你在4*4测试下设置并行度为4和8的情况，看看是什么结果.


 我是4X4的CPU，同一个Spid线程数远远超过4个。

[解决办法]
Mark
------解决方案-------------------- 
 
to pbsh:

我设置是的max degree of parallelism啊，必须的，你试试嘛。
[解决办法]
探讨

引用:
 to pbsh:

 我设置是的max degree of parallelism啊，必须的，你试试嘛。


 呵呵，我更改了一下max degree of parallelism，事实上任务管理器中逻辑CPU数目并没有发生变化。
 这两个应该不是同一个东西。

 有图有真相（求教这里如何上传图片？）

 你是不是设定了Boot.ini高级选项的参数/Numproc？这个参数是配置多少个逻辑CPU可用的。



[解决办法]
你找一个大表，然后select * from tbname where colname like '%value%'.
[解决办法]
根据楼主地描述有可能是 process block的问题，如果在执行过程中出现了block 的情况。那么cost threshold for parallelis 就需要配置的大一点，当然如果你需要serial执行的话。

建议：检查sql bug. 消除block.
[解决办法]
探讨

引用:
引用:
to pbsh:

我设置是的max degree of parallelism啊，必须的，你试试嘛。


呵呵，我更改了一下max degree of parallelism，事实上任务管理器中逻辑CPU数目并没有发生变化。
这两个应该不是同一个东西。

有图有真相（求教这里如何上传图片？）

你是不是设定了Boot.ini高级选项的参数/Numproc？这个参数是配置多少个逻辑CPU可用的。




没有加/Numproc . 我不只在一台服务器上做过测试了。而且在生产环境也有已配置过的server.

[解决办法]
好东西，顶。

同意留出1核的处理器的做法。
[解决办法]
探讨

引用:
 你找一个大表，然后select * from tbname where colname like '%value%'.
 误会你的意思了，原来你的意思是观察任务管理器中有曲线的窗口数目。

[解决办法]
哈哈  很好很强大 受启发了
[解决办法]
写的好啊 不错啊
[解决办法]
太复杂了。。
[解决办法]
.
[解决办法]
看完了.
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%.


[解决办法]
即然是压力测试，那就挨个设置试试效果。

实贱出真知啊~嘿
[解决办法]
我这目前等待最高是：SQLTRACE_BUFFER_FLUSH ，大约每台server占12%.

这是10台dell 2950的cxpacket等待(一周的时间)，我认为不需要处理。
wait_type wait_time_ms  %
CXPACKET608032.46
CXPACKET650702.63
CXPACKET194530.74
CXPACKET257521.06
CXPACKET637502.57
CXPACKET137270.57
CXPACKET180870.75
CXPACKET600742.44
CXPACKET137140.57
CXPACKET139650.58

[解决办法]
CXPACKET 如果排在第一位且>50%，cpu不可能会低的。
[解决办法]
因环境而异吧，自己的环境还是自己来测试出一个最佳值，有台server 8cpu. cxpacket之前在90%.
后来并行改为2cpu.现在是53%.

这台server全天cpu都>80%在跑各种各样的报表。

再过一周观察下，再改成1看情况.

不过cost threshold for parallelism这个值，似乎没有什么效果。
[解决办法]
探讨

分不是问题

[解决办法]
mark
------解决方案-------------------- 
 
探讨

引用:
 CXPACKET 如果排在第一位且>50%，cpu不可能会低的。


 你这个50%什么意思？状态为CXPACKET的线程数目百分比？

[解决办法]
探讨

引用:
 因环境而异吧，自己的环境还是自己来测试出一个最佳值，有台server 8cpu. cxpacket之前在90%.
 后来并行改为2cpu.现在是53%.

 这台server全天cpu都>80%在跑各种各样的报表。

 再过一周观察下，再改成1看情况.

 不过cost threshold for parallelism这个值，似乎没有什么效果。


 能不能讲一下你的OLAP数据库中常用的表是什么数量级，谢谢。
 

 

查看更多 下一篇