全部产品
Search
文档中心

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

更新时间:May 25, 2023

CPU使用率较高时,容易影响查询性能。本文介绍如何查看CPU使用情况以及排查CPU问题。

查看CPU使用情况

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

  • 监控与报警

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

    监控
  • 自治服务

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

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

    CloudDBA
说明

共享型实例会复用CPU,因此即使实例本身的CPU使用率不高,也可能会因为复用CPU导致性能出现瓶颈,如果对数据库性能的稳定性要求较高,建议使用独享型规格的实例。

分析性能指标

  • 原因

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

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

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

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

  • 分析

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

    QPSpage编译

    • 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_CountsCache_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)定位和分析这类查询语句。

  • 分析AAS

    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类报表,实际也是基于系统视图的,使用起来较为方便,但是不如直接查询系统视图灵活。

    CloudDBA

优化参数

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修改该参数,修改立即生效,无需重启实例。