如何对我的 Amazon RDS for SQL Server 实例上的高 CPU 利用率问题进行故障排除？

简短描述

以下原因可能会导致 CPU 利用率升高：

• 用户启动的繁重工作负载、多个并发查询或长时间运行的事务
• 为工作负载使用预置不足的实例类
• 统计数据过时，索引碎片或索引缺失
• 查询有待优化
• 阻塞和死锁
• 并行性
• 频繁编译和重新编译
• 参数嗅探
• 线程耗尽

要确定您的 Amazon RDS for SQL Server 实例的高 CPU 利用率的来源，请使用以下工具：

• Amazon RDS 的 Amazon CloudWatch 指标
• 增强监控
• 性能详情
• 数据库洞察
• SQL Server 工具

确定来源后，您可以分析和优化您的工作负载以降低高 CPU 利用率。

解决方法

Amazon RDS 的 CloudWatch 指标

使用 Amazon RDS 的 CloudWatch 指标来识别较长时段内的 CPU 模式。

要查找工作负载导致 CPU 利用率升高的时间段，请完成以下步骤：

1. 打开 Amazon RDS 控制台。
2. 在导航窗格中，选择 Databases（数据库），然后选择要监控的数据库。
3. 选择 Monitoring（监控）选项卡。
4. 选择 Monitoring（监控）菜单，然后选择 CloudWatch。
5. 搜索以下 CloudWatch 指标，然后比较图表：
   WriteIOPs
   ReadIOPs
   ReadThroughput
   WriteThroughput
   CPUUtilization
   CPUCreditBalance
   CPUCreditUsage

**注意：**如果 CPU 积分余额持续减少且 CPU 积分使用量持续增加，则表明没有足够的 CPU 内核来处理工作负载。如果您使用 t2 或 t3 实例类中的实例，请检查您的实例是否预置不足。

确定时间范围后，使用增强监控来更详细地查看与您的数据库实例关联的数据。您可以将增强监控设置为每隔 1、5、10、15、30 或 60 秒收集一次数据。

增强监控

您可以设置增强监控来监控在数据库实例上运行的操作系统 (OS)。

要使用增强监控检查 CPU 利用率，请完成以下步骤：

1. 打开 Amazon RDS 控制台。
2. 在导航窗格中，选择 Databases（数据库），然后选择要监控的数据库。
3. 选择 Monitoring（监控）选项卡。
4. 选择 Monitoring（监控）菜单，然后选择 OS process list（操作系统进程列表）。

验证操作系统进程、RDS 进程、SQL Server 进程或 SQL Agent 进程是否导致了高 CPU 利用率。您还可以检查这些进程使用的 CPU 和内存的百分比。

使用控制台监控性能指标。在 Monitoring（监控）选项卡上，选择 Monitoring（监控）菜单，然后选择 Manage graphs（管理图表）。

要确定 CPU 何时运行用户进程、运行内核或处于空闲状态，请选择 CPU User（CPU 用户）、CPU System（CPU 系统）、CPU Idle（CPU 空闲）指标对应的图表。然后，选择磁盘 I/O 和物理设备 I/O 的指标。这些指标包括读取 IO/s、写入 IO/s、读取 Kb/s 和写入 Kb/s。您还可以查看与内存相关的参数，包括可用内存、SQL Server 总内存和总内存。这些指标很有用，因为如果 CPU 花费更多时间等待资源，可能会导致 CPU 利用率很高。

有关详细信息，请参阅在 RDS 控制台中查看操作系统指标。

数据库洞察

使用 CloudWatch 数据库洞察对数据库负载的主要贡献者以及在一组实例上运行的单个操作系统进程进行故障排除。

默认情况下，会为 Amazon RDS 数据库开启数据库洞察的标准模式。要在创建或修改数据库实例时开启标准模式，请参阅开启适用于 Amazon RDS 的数据库洞察的标准模式。

**注意：**如果您未使用更广泛的权限，请务必授予数据库洞察所需的 IAM 权限。有关详细信息，请参阅开始使用 CloudWatch 数据库洞察。

有关 Amazon RDS 和实例类支持的详细信息，请参阅支持数据库洞察的 Amazon RDS 数据库引擎、区域和实例类。

性能详情

启用性能见解以识别造成数据库负载的查询。

完成以下步骤：

1. 访问性能详情控制面板。
2. 选中与要分析的时间范围对应的 Top SQL（主要 SQL）选项卡。
3. 确定耗时最长的查询。
4. 检查资源密集型查询以及在此期间观察到的等待事件。以下是经常与高 CPU 使用率相关的等待事件：

SOS_SCHEDULER_YIELD 表示一个 Worker 线程让出资源以便另一个线程运行。当等待次数多但等待时间短时，查询通常受 CPU 限制。当 Worker 线程让出资源时，受 CPU 限制的查询的等待时间可能会增加。如果等待时间很长，则必须查看工作负载。如果 SOS_SCHEDULER_YIELD 频繁发生，则问题在于 CPU 压力。查看工作负载类型并进行其他调整。

CXPACKET 和 CXCONSUMER 是与并行相关的等待事件，通常不用考虑。但是，如果这些等待事件频繁发生且会影响性能，请查看查询并为并行成本阈值设置适当的值。确保 SQL Server 在参数组中选择了成本较低的并行参数。您也可以在查询或实例级别将最大并行度 MAXDOP 增加到 1。

ThreadPool 表示线程耗尽。如果您的实例类能够处理此问题，请增加最大 Worker 线程数参数。当由于阻塞、高工作负载或大量并行查询导致使用过多线程时，您可能会遇到 ThreadPool 等待。此外，如果您错误配置了最大 Worker 线程数参数，则可能会遇到 ThreadPool 等待事件。

查看数据库指标，以了解批量请求、SQL 编译和 SQL 重新编译的次数。检查是否存在多次编译的查询。还要检查给定批次中的查询是否被频繁重新编译。如果是，则表明在查询代码中使用了 WITH RECOMPILE 子句。这两个原因都可能导致 CPU 使用率过高。

SQL Server 工具

要使用 SQL Server 工具对高 CPU 利用率问题进行故障排除，请执行以下操作：

• 分析特定查询，以了解高 CPU 利用率、统计数据更新、索引缺失和参数嗅探问题。有关详细信息，请参阅 Microsoft 网站上的对 SQL Server 中的高 CPU 使用率问题进行故障排除。
• 查看执行计划中是否存在性能不佳的查询，然后进行额外调整。有关详细信息，请参阅 Microsoft 网站上的显示实际执行计划。
• 使用查询和扩展事件来排查与过度锁定、阻塞和死锁相关的问题。有关详细信息，请参阅 Microsoft 网站上的了解和解决 SQL Server 阻塞问题。
  注意：在 RDS for SQL Server 中配置扩展事件时，不能使用标准方法来保存 .xel 文件。
• 使用 SQL Server 报告来微调您的工作负载。有关详细信息，请参阅 Microsoft 网站上的性能控制面板。