（转）SQL Server 性能调优（cpu）
Posted 众里寻它
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了（转）SQL Server 性能调优（cpu）相关的知识，希望对你有一定的参考价值。
摘自：http://www.cnblogs.com/Amaranthus/archive/2012/03/07/2383551.html
cost threshold for parallelism
cpu在sql server 中扮演了很重要的角色，虽然cpu绑定的服务器排除cpu问题相对比较简单，但并不意味着总是简单。如果你的1个或多个cpu满负荷运行，那么就要小心了。sql server 对cpu的使用无处不在，所以如果cpu满负荷运行，那么问题很严重。
cpu性能出现问题，一般很慢盘查为啥，因为会照成cpu性能问题的很多，如内存不足，数据换进换出，cpu一路飙高。写操作性能很烂，索引建的不合适，sql server 配置等问题都会引起cpu过高的问题。所以cpu性能盘查需要很小心和仔细。
不管是什么问题引发的，对cpu的性能分析就是把问题隔离到一个特定资源，我们可以使用perfmon，性能视图，还有sql跟踪来收集资源。
一旦发生问题，我们就要把问题锁定在一个或多个查询上，对其进行调整如调整cpu密集型的查询，添加合适的索引，使用存储过程替换ad hoc查询等等。
研究cpu压力工具
perfom
对于cpu压力的研究我们一般使用一下工具：perfmon，SQL跟踪，动态性能视图
perfmon我们可以跟踪如下性能指标：
Processor/ %Privileged Time --内核级别的cpu使用率
Processor/ %User Time --用户几倍的cpu使用率
Process (sqlservr.exe)/ %Processor Time --某个进程的cpu使用率
上面3个性能指标是全局范围的，SQL Satatistics 计数器虽然不能直接说明cpu的使用率但是可以间接的说明cpu的使用情况。
• SQLServer:SQL Statistics/Auto-Param Attempts/sec
• SQLServer:SQL Statistics/Failed Auto-params/sec
• SQLServer:SQL Statistics/Batch Requests/sec
• SQLServer:SQL Statistics/SQL Compilations/sec
• SQLServer:SQL Statistics/SQL Re-Compilations/sec
• SQLServer:Plan Cache/Cache hit Ratio
这些计数器没有额定的阀值，需要和性能基线做对比
SQL跟踪
SQL跟踪的具体用法就不多讲，很多人都已经会用了，SQL跟踪在某个时间点上的捕获远远不如动态性能视图，而且捕获的时候要注意设置过滤不然会捕获大量无用的sql。
性能视图
性能视图是分析的利器：
验证cpu压力的wait event 可以使用 sys.dm_os_wait_stats.
通过sys.dm_os_wait_stats和 sys.dm_os_schedulers，通过wait event 类型诊断。
可以用sys.dm_exec_query_stats和sys.dm_exec_sql_text说明使用大量cpu的执行计划
可以使用sys.dm_os_waiting_task查看cpu相关的等待类型
通过sys.dm_exec_requests查看当前正在的查询的资源使用情况
cpu相关的wait event
sql server 所有的等待信息，都会被记录。可以使用sys.dm_os_wait_stats中查看。这个视图可以用来确定cpu压力，查看cpu绑定系统中大多数的wait event。
Signal wait time
根据特定的等待类型(wait type)，有一些等待时间：
wait_time_ms该等待类型所有等待时间。
signal_wait_time_ms从发出信号到开始运行的时间差，时间花费在等待运行队列中，是单纯的cpu等待。
signal_wait_time_ms是所有等待时间的一个重要部分，说明了等待一个可用资源的等待时间。可以表示sql server 中是否正在运行cpu密集型查询。
下面代码量化的像是signal_wait_time_ms占的比重
SELECT SUM(signal_wait_time_ms) AS TotalSignalWaitTime ,
( SUM(CAST(signal_wait_time_ms AS NUMERIC(20, 2)))
/ SUM(CAST(wait_time_ms AS NUMERIC(20, 2))) * 100 )
AS PercentageSignalWaitsOfTotalTime
FROM sys.dm_os_wait_stats
这个dmv记录了统计信息，系统重启之后会被情况，所以如果查看某一时间点情况不是很好用，只能用临近的统计相减，也可以用 dbcc sqlperf清空统计信息。
关于session级和语句级的wait event 可以查看文章：http://sqlblog.com/blogs/jonathan_kehayias/archive/2010/12/30/an-xevent-a-day-30-of-31-tracking-session-and-statement-level-waits.aspx
我们可以使用sys.dm_os_wait_stats查看那个资源等待时间最长。top 10 用等待时间排序，但是这样就容易忽略一开始的等待也就是signal wait time，因此要减去signal_wait_time，作为等待调度器的时间。
下面讨论三个wait type 这三个和cpu压力息息相关。
SOS_SCHEDULER_YIELD等待
sql server 调度器是非抢占式调度，也就是说是依靠查询自动放弃cpu，但是windows是抢占式，也就是说一定时间之后，windows 会直接从cpu上删除任务。
当查询自动放弃cpu，并且等待恢复执行，这个等待就叫做SOS_SCHEDULER_YIELD,如果这个值很小那么就说明，花费在等待cpu上，而不是等待其他资源上。
如果sys.dm_exec_requests或者 sys.dm_os_waiting_tasks 的SOS_SCHEDULER_YIELD的等待值偏高，那么说明有cpu密集型查询，需要优化sql或者增加cpu。
CXPACKET等待
当同步查询进程，worker之间交换迭代器的时候发生CXPACKET等待，特别是发生并发查询的时候。如果是在
以上是关于（转）SQL Server 性能调优（cpu）的主要内容，如果未能解决你的问题，请参考以下文章