设为首页 收藏本站
查看: 1781|回复: 0

[经验分享] 如何识别SQL Server中的CPU瓶颈

[复制链接]

尚未签到

发表于 2016-10-31 09:20:16 | 显示全部楼层 |阅读模式
  原文出自:
  http://www.mssqltips.com/sqlservertip/2316/how-to-identify-sql-server-cpu-bottlenecks/
  
问题:
  如果经常遇到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/seccounter 计数器。在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(*) asnumber_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 XMLQueryHash属性中可以查看。
  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)包含的行数。
  

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-293655-1-1.html 上篇帖子: SQL Server 2008安装和配置图解 下篇帖子: SQL Server客户端连接问题解决
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表