SQL server 2008 R2 CPU使用问题，开4个CPU比开两个还卡，why？
我用的SQL Server 2008 R2 企业版，当分配所有4个CPU共64核时，系统CPU占用超过60%，前台工作不流畅。这时调整SQL分配的CPU，让SQL只占用2个CPU共32核时，系统CPU占用降低到10%~20%之间，前台客户端明显流畅了，百思不得其解。望高人指点！万分感谢！
------解决方案--------------------
首先先要用各种手段定位瓶颈——如DMV、性能计数器、R2自带的性能报表等。不定位，只有瞎猜，这样完全靠运气。
看你的描述可能是上下文切换过多引起的，个人觉得有可能你的代码不够优化，需要找出CPU开销较大的，然后进行优化。
最后你开4个CPU怎么就变成64核了？

除非你能准确定位问题，不然不要随便改微软的默认配置
------解决方案--------------------
是不是并发度太高，造成并发任务之间的相互等待太多。
试一下把Max Degree of parallelism的值设置为比较小的值。
------解决方案--------------------

引用:

是不是并发度太高，造成并发任务之间的相互等待太多。
试一下把Max Degree of parallelism的值设置为比较小的值。

同意，可以看一下WAIT TYPE是不是并发造成的。
------解决方案--------------------
现在的CPU有4个64核的吗？一个CPU有16核，这么离谱啊？是不是超线程了，如果是超线程的话，最后取消掉。
还有LZ可以看看CPU的架构，就明白多核CPU的好处和坏处。
------解决方案--------------------
感觉有可能是并行度问题。sql 有时候为了提高查询时间，
使用高并行的处理策略，这样会导致cpu开销多大
这也是部分语句会出现的
你可以跟踪一下cpu开销过大的查询。
这类语句的特点是cputime = 会比 elapsed time大很多
然后用option 限定一下maxdop 在试试
------解决方案--------------------

引用:

Quote: 引用:

感觉有可能是并行度问题。sql 有时候为了提高查询时间，
使用高并行的处理策略，这样会导致cpu开销多大
这也是部分语句会出现的
你可以跟踪一下cpu开销过大的查询。
这类语句的特点是cputime = 会比 elapsed time大很多
然后用option 限定一下maxdop 在试试

高并行的处理策略 导致的cpu开销大，直接好处是sql执行速度快很多！是好事

不一定，以前遇到过并行计划结果很慢，结果查看等待信息都是并行计划引起的，因为有的操作早就做完了，但是有的没做完，所以要一直等待。有的时候顺序执行可能效果好。 另外并行可能会影响系统反应，阻塞后面的语句执行（无法及时获得CPU资源）
------解决方案--------------------

引用:

首先先要用各种手段定位瓶颈——如DMV、性能计数器、R2自带的性能报表等。不定位，只有瞎猜，这样完全靠运气。
看你的描述可能是上下文切换过多引起的，个人觉得有可能你的代码不够优化，需要找出CPU开销较大的，然后进行优化。
最后你开4个CPU怎么就变成64核了？

除非你能准确定位问题，不然不要随便改微软的默认配置

引用:

核太多，互相切换的机会也多，各个核的cache里的数据也需要重复搬移到别的核的cache？
os是什么？是不是它对太多核的应对做的不够好？

这个问题问的有点晕，也许是我自己理解太浅。
就感觉这两位的答案好一点。5楼说的是NUMA
结构吗？高速缓存在CPU里而非内存里。NUMA结构好处在于每个节点处理访问自己的内存池不需要共享的总线，不需要额外的代价。如果访问数据在远程内存中，那么访问数据代价要高很多。所以只有两个NUMA就会把本地内存访问数量最大化。而不是4个就会访问远端内存吗？