我的 Amazon RDS for MySQL 或 Amazon Aurora MySQL 实例存在 CPU 使用率过高的问题,如何排查并解决?
我在 MySQL 数据库实例的 Amazon Relational Database Service (Amazon RDS) 或兼容 Amazon Aurora MySQL 的版本实例中发现 CPU 使用率很高。我该如何排查并解决高 CPU 使用率的问题?
简短描述
CPU 使用率的提高可能由多种因素造成,例如用户启动的繁重工作负载、多个并发查询或长时间运行的事务。
要确定 Amazon RDS for MySQL 实例中 CPU 使用率的来源,请查看以下方法:
- 增强监控
- Performance Insights
- 检测工作负载中 CPU 使用率的产生原因的查询
- 已激活监控的日志
在确定产生原因之后,您可以分析和优化工作负载,以减少 CPU 使用率。
解决方法
使用增强监控
增强监控提供操作系统 (OS) 级别的视图。此视图有助于在精细级别上确定高 CPU 负载的原因。例如,您可以查看负载平均值、CPU 分配(system% 或 nice%)和操作系统进程列表。
使用增强监控,以 1 分钟、5 分钟和 15 分钟的间隔检查 loadAverageMinute 数据。负载平均值大于 vCPU 数量,表示该实例负载很重。此外,如果负载平均值小于数据库实例类的 vCPU 数量,则应用程序延迟可能并非由 CPU 限制引起。检查负载平均值,以避免在诊断 CPU 使用原因时出现误报。
例如,如果您的数据库实例使用 db.m5.2xlarge 实例类且具有 3000 个预调配 IOPS(达到 CPU 限制),则可查看以下示例指标来确定高 CPU 使用情况的根本原因。在以下示例中,实例类具有与之关联的八个 vCPU。对于相同的负载平均值,超过 170 表示在测量的时间范围内计算机处于重负载:
负载平均分钟
15 | 170.25 |
5 | 391.31 |
1 | 596.74 |
CPU 利用率
用户 (%) | 0.71 |
系统 (%) | 4.9 |
Nice 值 (%) | 93.92 |
总计 (%) | 99.97 |
**注意:**与数据库实例上运行的其他任务相比,Amazon RDS 为您的工作负载赋予了更高优先级。为了优先处理这些任务,为工作负载任务指定较高的 Nice 值。因此,在增强监控中,Nice% 表示工作负载对数据库使用的 CPU 量。
开启增强监控后,还可检查与数据库实例关联的操作系统进程列表。增强监控显示最多 100 个进程。这可帮助您根据 CPU 和内存使用情况确定哪些进程对性能的影响最大。
在增强监控的操作系统 (OS) 进程列表部分,查看操作系统进程和 RDS 进程。确认 mysqld 或 Aurora 进程的 CPU 使用率百分比。这些指标可以帮助您确认 CPU 使用率的增加是源自操作系统进程还是 RDS 进程。或者,您可以使用这些指标来监控由 mysqld 或 Aurora 进程引起的任何 CPU 使用率增加。您还可以通过查看 cpuUtilization 的指标来了解 CPU 使用率的划分信息。有关更多信息,请参阅使用增强监控监控操作系统指标。
**注意:**如果激活性能架构,则可以将操作系统线程 ID 映射到数据库的进程 ID。有关更多信息,请参阅在内存足够时,为什么我的 Amazon RDS 数据库实例会使用交换内存?
使用性能详情
您可以使用性能洞察来识别在实例上运行且导致高 CPU 使用率的确切查询。首先,激活适用于 MySQL 的性能洞察。然后,您可以使用性能洞察来优化工作负载。请务必咨询您的 DBA。
要查看可以与性能洞察结合使用的数据库引擎,请参阅在 Amazon RDS 上使用性能洞察监控数据库负载。
使用查询来检测工作负载中 CPU 使用率的产生原因
在优化工作负载之前,必须确定有问题的查询。您可以在发生高 CPU 使用率问题时运行以下查询,以确定 CPU 使用率的根本原因。然后,优化工作负载以降低 CPU 使用率。
SHOW PROCESSLIST 命令会显示当前在 MySQL 实例上运行的线程。有时,同一组语句可能会继续运行而不完成。发生这种情况时,后续的语句必须等待第一组语句结束。这是因为 InnoDB 行级锁定可能正在更新相同的行。有关更多信息,请参阅 MySQL 网站上的 SHOW PROCESSLIST 语句。
SHOW FULL PROCESSLIST;
**注意:**以主要系统用户的身份运行 SHOW PROCESSLIST 查询。如果您不是主系统用户,则必须具有 MySQL PROCESS 服务器管理权限才能查看在 MySQL 实例上运行的所有线程。如果没有管理员权限,SHOW PROCESSLIST 只会显示与您正在使用的 MySQL 账户关联的线程。
INNODB_TRX 表提供有关当前正在运行且并非只读事务的 InnoDB 事务的信息。
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
INNODB_LOCKS 表提供有关 InnoDB 事务已请求但尚未收到的锁的信息。
对于 MySQL 5.7 或更早版本:
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
对于 MySQL 8.0:
SELECT * FROM performance_schema.data_locks;
INNODB_LOCK_WAITS 表针对每个被阻止的 InnoDB 事务提供一个或多个行。
对于 MySQL 5.7 或更早版本:
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
对于 MySQL 8.0:
SELECT * FROM performance_schema.data_lock_waits;
您可以运行类似于以下内容的查询,以查看哪些事务正在等待以及哪些事务正在阻止等待事务。有关更多信息,请参阅 MySQL 网站上的使用 InnoDB 事务和锁定信息。
对于 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;
SHOW ENGINE INNODB STATUS 查询提供来自标准 InnoDB 监视器的关于 InnoDB 存储引擎状态的信息。有关更多信息,请参阅 MySQL 网站上的 SHOW ENGINE 语句。
SHOW ENGINE INNODB STATUS;
SHOW [GLOBAL | SESSION] STATUS 提供有关服务器状态的信息。有关更多信息,请参阅 MySQL 网站上的 SHOW STATUS 语句。
SHOW GLOBAL STATUS;
**注意:**这些查询在 Aurora 2.x (MySQL 5.7)、Aurora 1. x (MySQL 5.6)、MariaDB 10.x 上进行了测试。此外,自 MySQL 5.7.14 起,INFORMATION_SCHEMA.INNODB_LOCKS 表不再受支持,并且已在 MySQL 8.0 中移除。performance_schema.data_locks 表取代了 INFORMATION_SCHEMA.INNODB_LOCKS 表。有关更多信息,请参阅 MySQL 网站上的 data_lock 表。
分析日志并开启监控
当您分析日志或希望在 Amazon RDS for MySQL 中激活监控时,请考虑以下方法:
- 分析 MySQL 常规查询日志以查看 mysqld 在特定时间执行的操作。您还可以查看特定时间在实例上运行的查询,包括有关客户端何时连接或断开连接的信息。有关更多信息,请参阅 MySQL 网站上的常规查询日志。
**注意:**如果长时间激活常规查询日志,日志会占用存储空间,并会增加性能开销。 - 分析 MySQL 慢速查询日志,查找运行时间超过 long_query_time 所设置秒数的查询。您还可以查看工作负载并分析查询以提高性能并减少内存占用。有关更多信息,请参阅 MySQL 网站上的慢速查询日志。**提示:**在使用慢速查询日志或常规查询日志时,请将参数 log_output 设置为 FILE。
- 使用 MariaDB 审计插件来审计数据库活动。例如,您可以跟踪登录到数据库的用户或针对数据库运行的查询。有关更多信息,请参阅 MariaDB 审计插件支持。
- 如果您使用的是 Aurora for MySQL,则还可使用高级审计。审计可以让您更好地控制要记录日志的查询类型。这样做可以减少日志记录的开销。
- 使用 innodb_print_all_deadlocks 参数来检查死锁和资源锁定。您可以使用此参数在 MySQL 错误日志中记录有关 InnoDB 用户事务中死锁的信息。有关更多信息,请参阅 MySQL 网站上的 innodb_print_all_deadlock。
分析和优化高 CPU 工作负载
确定导致 CPU 使用率增加的查询后,请优化工作负载以减少 CPU 消耗量。
如果您发现工作负载并不需要的查询,可以使用以下命令终止连接:
CALL mysql.rds_kill(processID);
要查找查询的 ProcessID,请运行 SHOW FULL PROCESSLIST 命令。
如果您不想终止查询,则使用 EXPLAIN 来优化查询。EXPLAIN 命令显示了运行查询过程中涉及的各个步骤。有关更多信息,请参阅 MySQL 网站上的使用 EXPLAIN 优化查询。
要查看配置文件详细信息,请激活 PROFILING。PROFILING 命令可以指示在当前会话期间运行的语句的资源使用情况。有关更多信息,请参阅 MySQL 网站上的 SHOW PROFILE 语句。
要更新任何表统计数据,请使用 ANALYZE TABLE。ANALYZE TABLE 命令有助于优化程序选择适当的计划来运行查询。有关更多信息,请参阅 MySQL 网站上的 ANALYZE TABLE 语句。
相关信息
如何激活和监控 Amazon RDS MySQL 数据库实例的日志?
Tuning Amazon RDS for MySQL with Performance Insights
相关内容
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前
- AWS 官方已更新 1 年前