检测SqlServer服务器CPU是否瓶颈

检测SqlServer服务器CPU是否瓶颈 初次写博文，分享个人心得，欢迎大虾小虾来拍砖。 系统自带的性能监视器 在开始命令框中输入perfmon按enter键即可打开性能监视器 可以通过监视 % Processor Time 的值察看cpu是否遇到瓶颈，此值最好不要超出80% 如果达到了比

检测SqlServer服务器CPU是否瓶颈

初次写博文，分享个人心得，欢迎大虾小虾来拍砖。

 

 系统自带的性能监视器

   在开始命令框中输入perfmon按enter键即可打开性能监视器

可以通过监视　% Processor Time 的值察看cpu是否遇到瓶颈，此值最好不要超出80%

如果达到了比较高的值也并不一定就是CPU的问题，一般来说CPU是不会有什么问题的，也有可能是IO，内存，网站空间，程序本身的问题，CPU只是表相而已

 可以用数据收集器定时收集

下面的语句可以查询出耗时最长的SQL语句

　　 select top 50 *, (s.total_worker_time / s.execution_count) as avgworkertime from sys.dm_exec_query_stats s
 cross apply sys.dm_exec_sql_text(s.sql_handle)
 order by avgworkertime desc

单位是微秒

 

SqlServer ProFile监视

选择TSQL_Duration模板监视SQL语句执行时长，可以选择保存为文件或者数据库，可以设置监视时长，监视的结果可以根据数据库引擎优化顾问进行优化

数据库引擎优化顾问可以优化SQL文件，虚拟主机，香港服务器租用，sqlserverprofile监视的文件或保存的数据表

 

在查询过程当中，编译查询计划是最为耗CPU的过程，以下可以查询出生成查询计划最多的SQL语句

select top 50 * from sys.dm_exec_query_stats q
cross apply sys.dm_exec_sql_text(q.sql_handle) t
order by q.plan_generation_num desc

尽可能的去优化这些SQL语句，以充分利用查询计划，可以大大提高查询效率

下面的语句可以查询出优化的结果

select * from sys.dm_exec_query_optimizer_info

占用时间           总优化次数     每次优化单个语句（查询）所用的平均时间（秒）。

elapsed time    11937503     0.140496722220612

SQL Statistics对象提供计数器来监视编译和发送到SQL Server实例的请求类型。必须通过监视查询编译和重编译的数量结合接收到的批处理数量来找出高CPU消耗是否是由编译引起。

理想情况下，SQL Recompilations/sec和Batch Requests/sec的比率应该应该非常低，除非用户提交的是即席查询。

关键数据：

SQLServer:SQL Statistics->Batch Requests/sec    

SQL Server: SQL Statistics: SQL Compilations/sec

SQL Server: SQL Statistics: SQL Recompilations/sec

SQL Trace

　　如果性能计数器显示非常大的重编译数量，重编译可能正在造成高CPU消耗。接下来需要需要利用SQL Profiler纪录的trace来找出当时被重新编译的存储

过程。SQL Server Profiler trace可以给出这些信息连同重编译的原因。可以使用事件来获取这些信息。

SP: Recompile / SQL: StmtRecompile. The SP:Recompile and the SQL:StmtRecompile事件类显示哪些存储过程和语句曾经被重新编译过。当编译一个存储过程时，为存储过程和每一个被编译的语句生成事件。然而，当一个存储过程被重新编译时，只有引起重新编译的语句才会被生成一个事件（不同于SQL Server 2000中的整体存储过程编译）。

 

　　SP:Recompile事件类中的重要的数据列如下所示：

　　◆Event Class

　　◆EventSubClass

　　◆ObjectID(表示包含这个语句的存储过程)

　　◆SPID

　　◆Start Time

　　◆SqlHandle

　　◆TextData

　　EventSubClass数据列对于确定重编译原因来说非常重要。一旦过程或者触发器被重新编译，SP:Recompile就会被触发，但是有可能被重编译的即席批处理不会引发这个事件。 在SQL Server 2005中，监视SQL:StmtRecompiles时非常有用的，任何类型的批处理，即席查询，存储过程或者触发器被重编译时，这个事件类都会被触发。

　　保存trace文件，使用下面的查询来查看所有的重编译事件。

Select spid,starttime,textdata,eventsubclass,objected,databaseid,
sqlhandle from fn_trace_gettable (‘filepath.trc’,1) where EventClass in(37,75,166)

　　EventClass 37是SP:Recompile, 75是CursorRecompile, 166是SQL:StmtRecompile.

　　也可以进一步对这些查询结果根据Sqlhandle和ObjectID列进行分组来查看是否有某个存储过程存在大量的重编译或者由于其他原因导致的重编译（如Set选项变化）。

　　Showplan XML For Query Compile. 这个事件类在Microsoft SQL Server编译或者重新编译SQL语句时发生。这个事件中有关于被编译或者重编译的语句的信息。这些信息包括查询计划和存在问题的过程的Object ID。如果发现SQL Compilations/sec计数器数值很高，应该监视这个事件类。通过这些信息可以发现哪些语句被频繁的重编译。可以使用这些信息改变那些语句的参数。这应该会降低重新编译的次数。

 

 

 

 

posted on

Copyright ©2013 gejianhua Powered by: 博客园 模板提供：沪江博客