SQL Server 2005性能测试实践 - CPU篇(1)

如果在没有额外复杂条件下突然出现CPU瓶颈，有可能是因为没有优化查询，错误的数据库配置，或者是数据库设计上的原因和硬件资源不足引起。在决定采用增加CPU数量或者使用更快速的CPU之前，应该先检查消耗CPU资源最多的操作是否能够被优化

如果发现性能计数器Processor: % Processor Time的值很高，每一个CPU的% Processor Time都超过80%时，可视为出现CPU瓶颈。也可以通过视图sys.dm_os_schedulers监视SQL Server的进程调度（schedulers）来确认可执行的任务是否为非零值。非零值表示任务被迫等待时间片来运行，如果这个数值非常高，说明存在 CPU瓶颈。

Select scheduler_id,current_task_count,runnable_task_count from sys.dm_os_schedulers where scheduler_id<255

下面的查询将给出一个较高层的视图来说明当前被缓存的消耗CPU资源最多的批处理或者过程。查询通过相同查询句柄的所有语句合计CPU的消耗情况。

Select top 50 sum (qs_total_worker_time) as total_cpu_time,sum(qs.execution_count) as total_execution_count, count(*) as number_of_statements,qs.plan_handle from sys.dm_exec_query_stats qs group by qs.plan_handle order by sum(qs.total_worker_time) desc

过多的compilation和recompilation

在批处理或者远程过程调用（RPC）提交到服务器执行之前，系统会检查查询计划的有效性和正确性。如果在检查过程中出现了失败的情况，这些批处理可能会被再次编译来产生新的查询计划。这样的编译被称为重编译（recompilations）。这些重编译一般必须确定正确性且通常在服务器认定在潜在数据发生变化后存在可能被优厚的查询计划时执行。编译的特性是CPU敏感的操作，因此过分的重编译可以导致CPU性能问题。