教你识别SQL Server中CPU瓶颈
作者:网络转载 发布时间:[ 2012/12/21 10:07:57 ] 推荐标签:
问题:
如果经常遇到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
另外一个用于探测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属性中可以查看。
Plan_generation_num列显示一个查询被重编译的次数。
SQLServer优化器尝试选择能提供快响应时间的执行计划,但是不代表总是低CPU利用。低效的查询计划会引起CPU的好用,此时同样可以使用sys.dm_exec_query_stats 来监控。
如果你想有一个对SQLServer优化所耗费时间的总览,可以检查:
sys.dm_exec_query_optimizer_info 。其中的消耗时间和后开销会非常有用。
可以使用以下DMVs来查询内部并行查询及其查询文本、执行计划的情况:
● sys.dm_exec_cached_plan: Shows the cached query plans.
● sys.dm_exec_requests: Shows each executing request in the SQL Server instance.
● sys.dm_exec_sessions: Shows all active user connections and internal tasks.
● sys.dm_exec_sql_text: Shows the text of the SQL batches.
● sys.dm_os_tasks: Shows each active task within SQL Server.
SQL Server Profiler:
如果性能监视器发现有问题,同样可以使用SQLServer Profiler来发现不必要的编译和重编译。SQLServer Profiler 跟踪能帮助你找到一直重编译的存储过程。可以使用下面的事件:
SP:Recompile, CursorRecompile, SQL:StmtRecompile: 这个事件是针对SQLServer的重编译。SP:Recompile事件中的EventSubClass 说明了重编译的原因。
● Showplan XML For Query Compile: 这个事件是针对T-SQL语句的重编译。包含了查询计划和过程的对象ID.注意对这个事件运行一个跟踪,能得到利用系统资源的重要信息。但是,如果性能计数器报告SQL Compilations/sec 的值很高时,跟踪将非常好资源。
低效的游标可以使用RPC:Completed事件来跟踪。查看sp_cursorfetch语句并检查第四个参数,包含每次提前(fetch)包含的行数。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11