如何故障排除并解决 Amazon RDS for MySQL 或 Aurora MySQL 兼容版数据库实例上的高 CPU 利用率问题？

简短描述

多种因素可能会导致 CPU 使用率增加，例如，用户启动的繁重工作负载、多个并发查询或长时间运行的事务。

要确定数据库实例中 CPU 使用率的来源，请检查以下资源：

• 增强监控
• 性能详情
• 检测工作负载中 CPU 使用率产生原因的查询
• 具有已激活监控的日志

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

解决方法

使用“增强监控”

增强监控提供操作系统 (OS) 级别的视图，以确定 CPU 负载过高的原因。例如，您可以查看负载平均值、操作系统进程列表和 CPU 分布（system% 或 nice%）。

借助增强型监控，您可以每隔 1、5 和 15 分钟检查 loadAverageMinute 数据。负载平均值大于 vCPU 数量表示该实例处于负载过重的状态。如果负载平均值小于数据库实例类的 vCPU 数量，则 CPU 节流可能不会导致应用程序延迟。为避免误报，在诊断 CPU 使用原因时，请检查负载平均值。

例如，您的数据库实例使用 db.m5.2xlarge 实例类，达到了 CPU 限制。该实例类有 8 个 vCPU 与之关联。负载平均值超过 170 表示计算机在测量的时间范围内处于重负载状态：

负载平均分钟数：

• 十五： 170.25
• 五： 391.31
• 一： 596.74

CPU 利用率：

• 用户 (%)： 0.71
• 系统 (%)： 4.9
• Nice (%)： 93.92
• 总计 (%)： 99.97

**注意：**Amazon RDS 会为工作负载提供比在数据库实例上运行的其他任务更高的优先级。为了确定与管理相关的任务的优先级，工作负载任务具有不同的 Nice 值。因此，在增强监控中，Nice (%) 表示工作负载对数据库使用的 CPU 量。

启用增强监控后，查看与数据库实例关联的操作系统进程列表。增强监控最多可显示 100 个进程。此列表可帮助您识别对 CPU 和内存性能影响最大的进程。

在增强监控的操作系统进程列表部分中，查看操作系统进程和 RDS 进程。这些指标有助于确认操作系统或 RDS 进程是否导致 CPU 使用率增加。或者，使用这些指标来监控 mysqld 或 aurora 进程使用的 CPU 百分比。如果 Aurora 存储进程守护程序在 Aurora 实例上显示高 CPU 使用率，则该实例的读/写工作负载很大。如此高的 CPU 使用率也可能表明实例大小对于当前的存储量和工作负载来说可能太小。或者，后台会发生复杂的操作。

要查看 CPU 使用率的划分，请查看 cpuUtilization 的指标。有关更多信息，请参阅使用增强监控来监控操作系统指标。

**注意：**如果您激活性能架构，则只能将操作系统线程 ID 映射到 RDS MySQL 数据库实例的进程 ID。您无法将操作系统线程 ID 映射到 Aurora MySQL 数据库实例的进程 ID。有关详细信息，请参阅为什么尽管内存足够，我的 Amazon RDS 数据库实例仍在使用交换内存？

使用数据库洞察

重要事项：性能详情将于 2025 年 11 月 30 日到期。您可以在 2025 年 11 月 30 日之前升级到数据库洞察的高级模式。如果您不进行升级，则使用性能详情的数据库集群将默认采用数据库洞察的标准模式。只有数据库洞察的高级模式才支持执行计划和按需分析。如果您的集群默认采用标准模式，则您可能无法在控制台上使用这些功能。要开启高级模式，请参阅开启适用于 Amazon Aurora 的数据库洞察的高级模式。另请参阅开启适用于 Amazon Aurora 的数据库洞察的高级模式。

您可以使用数据库洞察来识别在数据库实例上运行并导致 CPU 使用率高的查询。

首先，在您的 MySQL 实例上激活数据库洞察。然后，使用数据库洞察来优化您的工作负载。您可以与您的数据库管理员合作以确定问题的根本原因。

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

使用查询检测工作负载中 CPU 使用率的产生原因

在优化工作负载之前，必须先确定有问题的查询。要确定 CPU 利用率高的根本原因，请在出现高 CPU 问题时运行以下查询。

要查看在 MySQL 实例上运行的线程，请运行 SHOW FULL PROCESSLIST 命令：

SHOW FULL PROCESSLIST;

**注意：**以主系统用户身份运行 SHOW PROCESSLIST 查询。您必须拥有 MySQL PROCESS 服务器管理权限才能查看在 MySQL 实例上运行的所有线程。如果没有管理员权限，则 SHOW PROCESSLIST 仅会显示与您使用的 MySQL 账户关联的线程。

有时，同一组语句可能会继续运行而不完成。这种情况发生时，后续语句必须等待第一组语句完成。这是因为 InnoDB 行级锁定可能会更新相同的行。有关详细信息，请参阅 MySQL 网站上的 SHOW PROCESSLIST statement（SHOW PROCESSLIST 语句）。

INNODB_TRX 表提供有关所有运行的 InnoDB 事务（非只读事务）的信息。要查看 INNODB_TRX 表，请运行以下查询：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

INNODB_LOCKS 表提供有关 InnoDB 事务请求但未收到的锁的信息。要查看 INNODB_LOCKS 表，请运行以下查询：

MySQL 5.7 或更早版本：

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

MySQL 8.0：

SELECT * FROM performance_schema.data_locks;

有关详细信息，请参阅 MySQL 网站上的 MySQL 5.7 部分 INFORMATION_SCHEMA.INNODB_LOCKS 表和 MySQL 8.0 部分 data_locks 表。

INNODB_LOCK_WAITS 表会为每个被阻止的 InnoDB 事务提供一行或多行。要查看 INNODB_LOCKS_WAITS 表，请运行以下查询。

MySQL 5.7 或更早版本：

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

MySQL 8.0：

SELECT * FROM performance_schema.data_lock_waits;

要查看哪些事务正在等待以及哪些事务正在阻止等待事务，您可以运行类似于以下内容的查询：

MySQL 5.7 或更早版本：

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,  
  r.trx_query waiting_query,  
  b.trx_id blocking_trx_id,  
  b.trx_mysql_thread_id blocking_thread,  
  b.trx_query blocking_query  
FROM       information_schema.innodb_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_trx_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_trx_id;

MySQL 8.0：

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,  
  r.trx_query waiting_query,  
  b.trx_id blocking_trx_id,  
  b.trx_mysql_thread_id blocking_thread,  
  b.trx_query blocking_query  
FROM       performance_schema.data_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_engine_transaction_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_engine_transaction_id;

要解释此查询的输出，请参阅 MySQL 网站上的 MySQL 8.0 部分Using InnoDB transaction and locking information（使用 InnoDB 事务和锁定信息）。

要从标准 InnoDB 监控器获取有关 InnoDB 存储引擎状态的信息，请运行以下查询：

SHOW ENGINE INNODB STATUS;

有关详细信息，请参阅 MySQL 网站上的 MySQL 8.0 部分 SHOW ENGINE statement（SHOW ENGINE 语句）。

要查看服务器状态，请运行以下命令。

SHOW GLOBAL STATUS;

有关详细信息，请参阅 MySQL 网站上的 MySQL 8.0 部分 SHOW STATUS statement（SHOW STATUS 语句）。

要检查历史列表长度 (HLL)，请运行以下命令：

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

如果您的工作负载需要多个打开或长时间运行的事务，则数据库的 HLL 可能很高。此外，如果清除线程无法跟上数据库的变化，则您的 HLL 可能会很高。HLL 过高会导致更高的资源使用率以及 SELECT 语句的性能缓慢且不一致。

在 Aurora MySQL 写入实例上，使用 RollbackSegmentHistoryListLength CloudWatch 指标监控您的 HLL。

如果该实例的 HLL 较高，则检查您的 SQL 语句。当您应用 START TRANSACTION 且没有 COMMIT 提交时，就会出现此问题。由于线程进入了 SLEEP 状态，因此您看不到之前的 SQL 语句。

要解决此问题，请运行以下命令。

SELECT event_id, current_schema, sql_text, lock_time
 FROM performance_schema.events_statements_history
 WHERE thread_id=<thread_id>  
 ORDER BY event_id DESC;

分析日志并开启监控

分析 MySQL 常规查询日志，以查看 mysqld 在特定时间执行的操作。您还可以查看特定时间在实例上运行的查询，例如有关客户端何时连接或者断开连接的信息。有关详细信息，请参阅 MySQL 网站上的 The general query log（一般查询日志）。

**重要事项：**当您激活长时常规查询日志时，日志会消耗存储空间，并可能增加性能开销。

分析 MySQL 慢速查询日志，以找出运行时间超过为 long_query_time 设置的秒数的查询。您还可以查看工作负载并分析查询，以改善性能和内存消耗。有关更多信息，请参阅 MySQL 网站上的 7.4.5 慢速查询日志。

**注意：**当您使用慢速查询日志或常规查询日志时，最佳做法是将参数 log_output 设置为 FILE。

使用 MariaDB 审计插件审计 Amazon RDS for MySQL 或 Amazon RDS for MariaDB 上的数据库活动。例如，跟踪登录数据库的用户或跟踪对数据库运行的查询。

如果您使用 Aurora MySQL 兼容版，则可以使用高级审计。高级审计可以更好地控制要记录的查询类型，并减少日志记录的开销。

使用 innodb_print_all_deadlocks 参数检查死锁和资源锁定。您可以使用此参数在 MySQL 错误日志中记录有关 InnoDB 用户事务中死锁的信息。有关更多信息，请参阅 MySQL 网站上的 innodb_print_all_deadlocks。

分析并优化高 CPU 工作负载

在确定导致 CPU 使用率增加的查询后，优化您的工作负载，以降低 CPU 消耗。

如果发现工作负载不需要的查询，请运行以下命令终止连接：

CALL mysql.rds_kill(processID);

**重要事项：**当终止实例上的数据操作语言 (DML) 写入时，该实例会回滚被中断的事务。回滚更新可能需要很长时间。如果您的查询运行了很长时间，请与您的数据库管理员一起检查是否可以停止查询。

要查找查询的 processID，请运行 SHOW FULL PROCESSLIST 命令。

如果不想结束查询，请使用 EXPLAIN 来优化查询。EXPLAIN 会显示运行查询时所涉及的各个步骤。有关详细信息，请参阅 MySQL 网站上的 Optimizing Queries with EXPLAIN（使用 EXPLAIN 优化查询）。

要查看配置文件的详细信息，请激活 profiling。SHOW PROFILE 命令会显示当前会话期间运行的语句的资源使用情况。有关详细信息，请参阅 MySQL 网站上的 SHOW PROFILE statement（SHOW PROFILE 语句）。

要查看和优化表统计数据，请使用 ANALYZE TABLE 查询。有关详细信息，请参阅 MySQL 网站上的 ANALYZE TABLE statement（ANALYZE TABLE 语句）。

相关信息

使用等待事件优化 Aurora MySQL

如何激活和监控 Amazon RDS for MySQL 数据库实例的日志？

Amazon CloudWatch Database Insights applied in real scenarios（应用于真实场景的 Amazon CloudWatch 数据库洞察）