sqlserver处理器,sqlserver管理器

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

如何识别SQL Server中的CPU瓶颈

问题：

如果经常遇到CPU瓶颈而导致的SQLServer宕机，那如何去发现并解决这些相关的问题？

解决方案：

导致CPU成为SQLServer性能问题的原因有很多，比较明显的原因是因为资源不足。但是，CPU的利用率可以通过配置的更改和查询的优化来降低，所以当你想买更快更好的处理器之前，先要考虑前面的操作。下面是使用一些内置工具来识别CPU相关瓶颈：

性能监视器（Performance Monitor）：

可以使用性能监视器来检查CPU的负载。检查Processor:% Processor Time 这个计数器：如果长期超过80%/处理器，那很有可能面临了CPU相关瓶颈。

CPU密集操作主要是编译和重编译。你可以通过使用SQL Statistics对象计数器来监视它们的情况。也可以监控批处理接收的数量来查看。如果SQL Recompilations/sec 中的BatchRequests/sec的速率很高，那就有潜在的问题：

配置和监视以下计数器：

SQL Server: SQL Statistics: SQL Compilations/sec

SQL Server: SQL Statistics: SQL Recompilations/sec

SQL Server: SQL Statistics: Batch Requests/sec

可以从MSDN中获取关于这部分的详细信息： MSDN Library.

另外一个用于探测CPU相关问题的计数器是：SQL Server: Cursor Manager By Type – CursorRequests/Sec ，用于显示你的服务器上游标使用情况。如果你看到每秒有数以百计的游标请求，那很有可能是因为低效的游标使用和小体积提取操作（small fetch size）引起性能问题。

内部并行查询同样会引起CPU问题，可以检查：

SQL Statistics:Batch Requests/sec counter 计数器。在CPU生命周期中，每秒的批处理应该很小。如果过多，意味着正在使用并行计划运行。

动态管理视图（DMVs）：

以下是对排查CPU瓶颈游泳的DMVs。动态视图：sys.dm_exec_query_stats显示目前缓存的批处理或者使用CPU的过程。下面的查询用于检查耗费CPU的执行计划：

select plan_handle,

sum(total_worker_time) as total_worker_time,

sum(execution_count) as total_execution_count,

count(*) as number_of_statements

from sys.dm_exec_query_stats

group by plan_handle

order bysum(total_worker_time), sum(execution_count) desc

SQLServer2008在每个查询编译时，会计算其hash值。你可以在query_hash列中找到该值，是否两个查询仅仅字面值不同但是使用相同query_hash值。该值也在 Showplan/Statistics XML QueryHash属性中可以查看。