云数据库 RDS：RDS SQL Server CPU使用率高问题

查看CPU使用情况

RDS管理控制台提供多种查看CPU使用情况的方法：

• 监控与报警

  在控制台的监控与报警页面，单击旧版监控页签，在资源监控内，可以查看CPU使用率信息。

  

• 自治服务

  实例不能是RDS SQL Server 2008 R2云盘版。

  在控制台的自治服务 > 性能优化页面，单击性能洞察页签，可以查看CPU使用率信息。

  

分析性能指标

• 原因

  对于突发的CPU使用率明显增高情况，常见原因有如下几种：

  • 数据库查询请求数量突然增加。例如业务负载突然增加，或是数据缓存服务层出现缓存穿透等。

  • 查询请求的开销突然增加。例如应用中出现新的低效查询请求，或是某些查询语句的执行计划发生了改变等。

  • 查询语句的执行计划编译频率明显增加。例如当实例的缓存压力增大时，会导致执行计划缓存数量明显下降和缓存命中率下降，并进一步造成查询语句编译的频率和整体开销明显增加。

• 分析

  在监控中重点关注如下性能指标，可以初步判断是哪种原因导致的CPU使用率增高。

  

  • QPS

    如果QPS增高和CPU使用率增高保持一致，说明是数据库查询请求数量增加导致的CPU使用率增高，即CPU高的原因不在数据库层面，应当从应用层面分析是什么原因导致数据库查询请求数量增加。

  • Page_Lookups/sec

    Page_Lookups/sec是指执行中的查询请求平均每秒累积的逻辑读页数，Page_Lookups/sec高的原因通常是查询语句的执行效率较差，该值如果较高，则查询请求的CPU开销也一定较高。如果Page_Lookups/sec的增高和CPU使用率的增高保持一致，而QPS变化不大，说明数据库中出现了查询语句执行开销增高的情况，需要进一步分析是哪些类型的查询语句导致了较高的CPU资源消耗，并针对具体的查询语句进行优化。

  • Sqlcompliations

    Sqlcompliations是指平均每秒查询请求的编译次数，如果Sqlcompliations的增高和CPU使用率的增高保持一致，而QPS变化不大，可能是查询请求的编译开销导致的CPU增高，还可以进一步检查与执行计划缓存数量相关的性能指标Cache_Object_Counts和Cache_Pages，如果这些性能指标的值下降也很明显，则较大可能是实例的缓存压力过大。提高实例的内存规格是比较有效的解决方法。

• 参考案例

  以下为一个实际的参考案例。

  

  从CPU使用率的监控中可以看到，CPU的升高主要出现在9:10~9:20和9:30~9:40这两个时段。该实时段内实例的QPS并没有增加，9:40之后QPS才开始增加，因此CPU使用率的增高并不是数据库查询请求数量的增加导致的。

  同时段Sqlcompliations的值也无明显升高，并且其绝对值也很低，因此查询编译开销也不是导致CPU升高的原因。

  Page_Lookups/sec的值增高与CPU使用率的增高时间基本一致，因此较大的可能性是9:10~9:20和9:30~9:40这两个时段内有某些执行开销较高的查询请求存在，导致了实例整体CPU使用率的明显升高。

  在这种情况下，需要进一步分析在上述时段内有哪些查询语句的执行导致了较高的CPU资源消耗。另外Page_Lookups/sec的值升高一定会导致CPU使用率升高，但也会有些查询语句的执行开销很高而逻辑读开销并不高，这时要分析对应时段内的查询语句以定位原因。

分析活动会话

• 原因

  导致RDS SQL Server实例的CPU使用率突然增高的各种原因中，最常见的是数据库中出现了某些执行效率较差的查询语句。您可以使用自治服务中性能洞察功能的平均活跃会话AAS（Average Active Sessions）定位和分析这类查询语句。

• 分析

  RDS会每10秒检查一次SQL Server实例中的活动会话（Active Session）信息，并记录当前处于活动状态的查询请求的SQL语句、Query Hash、执行计划及等待事件类型等。CPU开销高的查询语句处于执行状态的过程中有很大可能其等待类型（Waits）是CPU。

  SQL Hash列的值是对SQL语句进行结构参数化之后的哈希值，用于标识在语句结构上完全相同的一类SQL语句，便于将SQL语句按照结构进行归类聚合统计，利用SQL Hash可以直接在系统视图sys.dm_exec_query_stats中基于query_hash列的值进行检索，从而获得该语句的最新执行情况统计信息。

  建议的排查方法如下：

  • 单击SQL Hash列的超链接，可以查看该语句本身的AAS统计结果。

  • 单击执行计划列的分析，可以查看SQL语句的执行计划，以及自治服务分析后给出的性能优化参考建议。

  以上建议是基于常规的优化策略，对于结构较为简单的SQL语句来说，效果会比较好，但对于复杂的SQL语句，建议您在参考以上优化建议的基础上，对执行计划的信息进行具体的分析并做实际测试验证。

  关于AAS的更多介绍，请参见性能洞察。

分析Top SQL

• 原因

  利用自治服务性能洞察中的AAS功能，可以方便地定位特定时段内导致CPU使用率升高的SQL语句，但是不能提供各类SQL语句的执行频率、平均CPU开销、整体CPU资源消耗占比等信息。从优化实例的整体CPU资源效率的角度考虑，获取CPU资源消耗Top SQL语句的详细统计信息是很有必要的。

• 分析

  SQL Server支持自动汇总统计SQL语句和存储过程等对象的执行信息，并可通过sys.dm_exec_query_stats和sys.dm_exec_procedure_stats等系统视图直接查看，便于定位各类资源开销的Top SQL。

  说明

  自治服务性能优化中的TOP SQL、TOP Objects报表，以及Management Studio中自带的Top query类报表，实际也是基于系统视图的，使用起来较为方便，但是不如直接查询系统视图灵活。

  

优化参数

SQL Server实例的最大并行度MAXDOP（max degree of parallelism）用于控制单个查询请求可以同时使用的最大活跃线程数（也即CPU核数）。对于CPU开销较高的SQL语句，如果使用并行度较高的执行计划，执行时间可能会显著缩短，但也意味着单位时间内的CPU资源消耗会明显增加。因此设置最大并行度需要在执行速度和CPU使用率之间进行平衡，建议如下：

• 查询请求的并发量较高，大部分SQL语句的执行开销较低时，MAXDOP的值应小一些，甚至为1（即完全无并行）。

• 查询请求的并发量较低，同时存在一些执行开销较高的SQL语句，MAXDOP的值应大一些，建议不超过实例可使用的最大CPU核数的1/2或1/4。

MAXDOP的默认值为2，是一个相对平衡保守的设置。您可以通过RDS专用的存储过程sp_rds_configure修改该参数，修改立即生效，无需重启实例。