# 排查 Aurora MySQL 数据库的工作负载问题
数据库工作负载可以看作是读取和写入。了解“正常”数据库工作负载后，您可以调整查询和数据库服务器，来满足不断变化的需求。性能可能发生变化的原因有很多，因此第一步是了解发生了什么变化。
+ 是否进行了主要版本或次要版本升级？
主要版本升级包括对引擎代码的更改，尤其是优化器中的更改，这些更改可能会更改查询执行计划。升级数据库版本，尤其是主要版本时，分析数据库工作负载并相应进行调整非常重要。调整可能包括优化和重写查询，或者添加和更新参数设置，具体取决于测试的结果。了解造成影响的原因将使您能够开始专注于该特定区域。
有关更多信息，请参阅 MySQL 文档中的 [What is new in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) 和 [Server and status variables and options added, deprecated, or removed in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html)，以及[比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3](AuroraMySQL.Compare-v2-v3.md)。
+ 正在处理的数据（行计数）是否有所增加？
+ 是否有更多查询并行运行？
+ 模式或数据库是否发生变化？
+ 是否存在代码缺陷或修复？
**Contents**
+ [实例主机指标](#ams-workload-instance)
+ [CPU 使用率](#ams-workload-cpu)
+ [内存使用量](#ams-workload-instance-memory)
+ [网络吞吐量](#ams-workload-network)
+ [数据库指标](#ams-workload-db)
+ [排查 Aurora MySQL 数据库的内存使用问题](ams-workload-memory.md)
+ [示例 1：持续的高内存使用量](ams-workload-memory.md#ams-workload-memory.example1)
+ [示例 2：短暂内存峰值](ams-workload-memory.md#ams-workload-memory.example2)
+ [示例 3：可释放内存持续下降且无法回收](ams-workload-memory.md#ams-workload-memory.example3)
+ [排查 Aurora MySQL 数据库内存不足问题](AuroraMySQLOOM.md)
## 实例主机指标
监控 CPU、内存和网络活动等实例主机指标，来协助了解工作负载是否发生了变化。了解工作负载变化有两个主要概念：
+ 利用率 - 设备（例如 CPU 或磁盘）的使用情况。它可以是基于时间的，也可以是基于容量的。
+ 基于时间 - 资源在特定观察期内忙碌的时间量。
+ 基于容量 – 系统或组件可以提供的吞吐量，以其容量的百分比表示。
+ 饱和度 - 资源需要的工作量超过其处理能力的程度。当基于容量的使用率达到 100% 时，将无法处理额外的工作，必须排队。
### CPU 使用率
您可以使用以下工具来确定 CPU 使用率和饱和度：
+ CloudWatch 提供了 `CPUUtilization` 指标。如果该指标达到 100%，则实例饱和。但是，CloudWatch 指标按 1 分钟取平均值，因而粒度不足。
有关 CloudWatch 指标的更多信息，请参阅[Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
+ 增强监控提供由操作系统 `top` 命令返回的指标。它以 1 秒的粒度显示平均负载和以下 CPU 状态：
+ `Idle (%)` = 空闲时间
+ `IRQ (%)` = 软件中断
+ `Nice (%)` = 对于优先级为 [niced](https://en.wikipedia.org/wiki/Nice_(Unix)) 的进程，状态为 Nice 的时间。
+ `Steal (%)` = 为其他租户提供服务所花费的时间（与虚拟化相关）
+ `System (%)` = 系统时间
+ `User (%)` = 用户时间
+ `Wait (%)` = I/O 等待
有关增强监控指标的更多信息，请参阅 [Aurora 的操作系统指标](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS)。
### 内存使用量
如果系统面临内存压力，并且资源消耗达到饱和，则应观察到高程度的页面扫描、分页、交换和内存不足错误。
您可以使用以下工具来确定内存使用量和饱和度：
CloudWatch 提供了 `FreeableMemory` 指标，该指标显示通过刷新部分操作系统缓存和当前可用内存可以回收多少内存。
有关 CloudWatch 指标的更多信息，请参阅[Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
增强监控提供以下指标，有助于您识别内存使用量问题：
+ `Buffers (KB)` – 在写入存储设备前用于缓冲 I/O 请求的内存量（以 KB 为单位）。
+ `Cached (KB)` – 用于缓存基于文件系统的 I/O 的内存量。
+ `Free (KB)` – 未分配的内存量（以 KB 为单位）。
+ `Swap` –“已缓存”、“可用”和“总计”。
例如，如果您看到您的数据库实例使用 `Swap` 内存，则您的工作负载的内存总量将大于您的实例当前可用的内存量。我们建议增加数据库实例的大小或调整工作负载来使用更少的内存。
有关增强监控指标的更多信息，请参阅 [Aurora 的操作系统指标](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS)。
有关使用性能架构和 `sys` 架构来确定哪些连接和组件正在使用内存的更多详细信息，请参阅 [排查 Aurora MySQL 数据库的内存使用问题](ams-workload-memory.md)。
### 网络吞吐量
CloudWatch 提供以下网络总吞吐量指标，所有指标均按 1 分钟取平均值：
+ `NetworkReceiveThroughput` – Aurora 数据库集群中每个实例从客户端接收的网络吞吐量。
+ `NetworkTransmitThroughput` – Aurora 数据库集群中每个实例发送到客户端的网络吞吐量。
+ `NetworkThroughput` – Aurora 数据库集群中每个实例从客户端接收和发送到客户端的网络吞吐量。
+ `StorageNetworkReceiveThroughput` – 数据库集群中每个实例从 Aurora 存储子系统接收的网络吞吐量。
+ `StorageNetworkTransmitThroughput` – Aurora 数据库集群中每个实例发送到 Aurora 存储子系统的网络吞吐量。
+ `StorageNetworkThroughput` – Aurora 数据库集群中每个实例从 Aurora 存储子系统接收与发送到该子系统的网络吞吐量。
有关 CloudWatch 指标的更多信息，请参阅[Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
增强监控提供 `network` 已接收（**RX**）和已发送（**TX**）图表，粒度高达 1 秒。
有关增强监控指标的更多信息，请参阅 [Aurora 的操作系统指标](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS)。
## 数据库指标
检查以下 CloudWatch 指标，来了解工作负载变化：
+ `BlockedTransactions` – 每秒内数据库中被阻止的事务的平均数。
+ `BufferCacheHitRatio` – 缓冲区缓存提供服务的请求的百分比。
+ `CommitThroughput` – 每秒平均提交操作数量。
+ `DatabaseConnections` – 连接至数据库实例的客户端网络连接数。
+ `Deadlocks` – 每秒内数据库中死锁的平均数。
+ `DMLThroughput` – 每秒平均插入、更新和删除数。
+ `ResultSetCacheHitRatio` – 查询缓存提供服务的请求的百分比。
+ `RollbackSegmentHistoryListLength` – 记录已提交事务（带有删除标记的记录）的撤销日志。
+ `RowLockTime` – 为 InnoDB 表获取行锁定所花的总时间。
+ `SelectThroughput` – 每秒平均选择查询数。
有关 CloudWatch 指标的更多信息，请参阅[Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
检查工作负载时，请考虑以下问题：
1. 数据库实例类最近是否发生了变化，例如，将实例大小从 8xlarge 缩小到 4xlarge，或者从 db.r5 更改为 db.r6？
1. 您能否创建一个克隆并重现此问题，或者该问题只发生在那一个实例上？
1. 是否存在服务器资源耗尽、CPU 过高或内存耗尽的问题？ 如果是，则这可能意味着需要额外的硬件。
1. 一个或多个查询是否需要更长的时间？
1. 这些更改是否由升级（尤其是主要版本升级）引起？ 如果是，则比较升级前和升级后的指标。
1. 读取器数据库实例的数量是否发生了变化？
1. 您是否启用了常规、审计或二进制日志记录？ 有关更多信息，请参阅 [Aurora MySQL 数据库日志记录](aurora-mysql-troubleshooting-logging.md)。
1. 您是否启用、禁用或更改了对二进制日志（binlog）复制的使用？
1. 是否存在任何持有大量行锁的长期运行的事务？ 检查 InnoDB 历史记录列表长度（HLL），来获取长时间运行的事务的指示。
有关更多信息，请参阅[InnoDB 历史记录列表长度显著增加](proactive-insights.history-list.md)和博客文章 [Why is my SELECT query running slowly on my Amazon Aurora MySQL DB cluster?](https://repost.aws/knowledge-center/aurora-mysql-slow-select-query)
1. 如果写入事务导致 HLL 较大，则表示 `UNDO` 日志正在累积（未定期清理）。在大型写入事务中，这种累积可能会迅速增长。在 MySQL 中，`UNDO` 存储在 [SYSTEM 表空间](https://dev.mysql.com/doc/refman/5.7/en/innodb-system-tablespace.html)中。`SYSTEM` 表空间不可收缩。`UNDO` 日志可能会导致 `SYSTEM` 表空间增长到若干 GB，甚至 TB。清除后，通过对数据进行逻辑备份（转储）来释放分配的空间，然后将转储导入到新的数据库实例。
1. 如果较大的 HLL 是由读取事务（长时间运行的查询）引起的，则可能意味着该查询使用了大量的临时空间。通过重启来释放临时空间。检查 Performance Insights 数据库指标，来了解 `Temp` 部分（例如 `created_tmp_tables`）是否有任何变化。有关更多信息，请参阅 [在 Amazon Aurora 上使用性能详情监控数据库负载](USER_PerfInsights.md)。
1. 能否将长时间运行的事务拆分为修改较少行的较小事务？
1. 被阻止的事务是否有任何变化或死锁是否增加？ 检查 Performance Insights 数据库指标，来了解 `Locks` 部分中的状态变量（例如 `innodb_row_lock_time`、` innodb_row_lock_waits` 和 ` innodb_dead_locks`）是否有任何变化。使用 1 分钟或 5 分钟间隔。
1. 等待事件是否增加？ 以 1 分钟或 5 分钟间隔检查 Performance Insights 等待事件和等待类型。分析排名靠前的等待事件，看看它们是否与工作负载变化或数据库争用相关。例如，`buf_pool mutex` 表示缓冲池争用。有关更多信息，请参阅 [使用等待事件优化 Aurora MySQL](AuroraMySQL.Managing.Tuning.wait-events.md)。