SQL Server高CPU使用故障排除

q968

　　SQL Server高CPU使用故障排除
　　翻译自：https://mssqlwiki.com/2012/10/04/troubleshooting-sql-server-high-cpu-usage/
　　第一件事情是确认当系统上有高CPU使用时，是否SQL Server在消耗CPU资源或者是其它应用程序或服务。
　　使用这个查询（https://mssqlwiki.com/2010/11/30/how-to-find-sql-server-and-system-cpu-usage-history/）来获取CPU使用历史，或者使用任务管理器，或者使用Perfmon计数器来确认。在Perfmon，Process里的%Process time也可以被使用。记住该计数器不是基于100%。它是基于处理器的数量。如果对于sqlservr.exe看到200并且系统有8个CPU，那么sqlservr.exe消耗的CPU为800中的200（只有25%）。
　　是否CPU峰值是由其他应用程序包括应用程序组所导致。
　　下一步是确定CPU消耗的是内核时间还是用户时间。
　　我们可以在Perfmon中使用Process的%Privileged time和%user Time计数器。任务管理器里将显示内核时间也会帮助我们理解。
　　内核CPU：
　　通常，如果内核CPU保持10%以下，是正常的。但是如果你看到内核CPU持续在30%或以上，你应该开始查看系统驱动、防病毒软件等。一些会增加内核CPU时间的已知问题：

• 　　一些防病毒软件可以导致高内核时间。临时禁止防病毒软件可以排除它。
  
• 　　我们可以在SQL Server 2008或者SQL Server 2005 SP3里看到高精度定时器（high resolution timer）在虚拟机由于过期的BIOS而导致高内核时间。通过打开跟踪标志8038（配置为启动参数）临时禁止高精度定时器可以证明这一点。检查BIOS更新并长期不使用8038。
  

　　高用户CPU：
　　在SQL Server里一些最常见的原因是：

• 　　查询执行导致了CPU峰值（最有可能是优化器采用了糟糕的计划）。
  
• 　　高的编译和重编译。（结构和统计信息修改，临时表的使用，重编译提示）。
  
• 　　系统线程消耗CPU（Ghost cleanup、Lazy writer、Resource monitor）。
  
• 　　运行了很多跟踪。
  

　　1. 查询执行导致CPU峰值：
　　查询执行花了很长时间和CPU峰值一般是因为过期的统计信息、缺少索引、服务器配置、分布式查询等导致不正确的基数预估。
　　当服务器正经历这个问题，运行以下链接的查询，根据CPU时间姜旭排列列出服务器上正在执行的所有查询和计划。
　　获取所有正在执行的语句的SQL文本和查询计划：https://mssqlwiki.com/2010/02/01/how-to-get-sql-text-and-query-plan-for-statements-which-are-executing-now/
　　可能是一个查询消耗大多数CPU时间或者是多个查询每个消耗CPU。查看以上查询输出的CPU时间。
　　
　　如果是单个查询或者存储过程消耗大多数CPU：

• 　　更新该查询使用的表和索引的统计信息（如果统计信息到目前为止在执行计划里Estimated rows和estimated execution大约相等。如果有大量不同的统计信息过期并且需要更新）。
  
• 　　识别查询是否因为参数嗅探而使用了糟糕的执行计划（如果在XML执行计划里ParameterCompiledValue和ParameterRuntimeValue不同）。参考这个链接（https://mssqlwiki.com/2012/10/08/parameter-sniffing/）链接更多关于参数嗅探。
  
• 　　如果更新统计信息和修复参数嗅探都不能解决这个问题，很有可能优化器由于缺少索引和正确的统计信息而不能创建有效的计划。在数据库优化向导里运行消耗CPU的查询，并应用推荐。（你可以在XML计划里找到缺失索引详情，但是DTA更有效）你可以跟着以下步骤：使用SQL Server数据库调优向导调优查询（http://sqlserverscribbles.com/2013/06/01/sql-server-database-tuning-advisor/）。
  
• 　　如果消耗CPU的查询时链接服务器查询，尝试修改连接服务器的安全性，以确保链接服务器用户在远程服务器上有ddl_admin或者dba/sysadmin权限。关于这个问题的更多详情，请参考：http://blogs.msdn.com/b/psssql/archive/2009/09/02/distributed-queries-remote-login-permissions-and-execution-plans.aspx。
  
• 　　确保优化器没有很早终止并创建糟糕的执行计划。更多详情请参考：https://mssqlwiki.com/2012/10/07/optimizer-timeout-or-optimizer-memory-abort/。
  
• 　　确保消耗CPU的查询没有计划向导（XML计划将有PlanGuideDB属性。sys.plan_guides里也有条目）和查询提示（index=或(option xxx join)或inner (Join Hint) join）。
  
• 　　确保SET选项没有改变。
  

　　如果是多个查询或存储过程一起消耗CPU：

• 　　更新数据里的所有表和索引的统计信息。使用以下链接中的查询：对于数据库里的所有表更新索引和统计信息（https://mssqlwiki.com/2010/09/26/how-to-rebuild-index-and-update-statistics-for-all-the-tables-in-database/）。
  
• 　　如果更新统计信息没有帮助并且重建索引不能降低CPU，我们只有逐一调优查询。
  
• 　　确保大量的RAM没有导致优化器去选择无效的计划：http://support.microsoft.com/kb/2413549
  
• 　　确保我们没有在同时运行很多跟踪（通常来源于监控工具）。我们使用以下查询来列出所有的活跃跟踪：找出运行在SQL Server的所有Profiler跟踪（https://mssqlwiki.com/2010/04/26/how-to-find-all-the-profiler-traces-running-on-my-sql-server/）。
  

　　2. 如果系统线程正消耗大多数CPU。
　　

• 　　如果没有SQL查询正在消耗大多数CPU，我们可以通过查询后端线程的yssprocesses输出来识别是否后端线程正在消耗大多数CPU。
  　　select * from sys.sysprocesses where spid