DevOps知识中心
DevOps知识中心

排查 AWS RDS 突发性能下降的五个步骤

了解快速诊断并解决 AWS RDS 数据库突发性能下降的五个基本步骤。本指南提供了一套系统的方法，从使用 CloudWatch 和 Performance Insights 进行即时指标分析开始。探索如何识别资源瓶颈（CPU、I/O、连接），利用执行计划精确定位慢查询，并验证关键实例配置，例如 T 系列积分余额和参数组设置，以确保高效恢复数据库的最佳性能。

35 浏览量

AWS RDS 性能突然下降的五步故障排除指南

生产数据库性能突然下降是运维团队面临的最严峻问题之一。Amazon Relational Database Service (RDS) 简化了数据库管理，但对意外缓慢问题的故障排除——表现为高延迟、事务超时或应用程序错误——仍然需要系统化、专注的方法。

本指南概述了五种实用、可行的步骤，用于快速识别 AWS RDS 实例性能下降的根本原因，重点关注利用内置的 AWS 监控工具和标准的数据库诊断技术。通过遵循这种顺序方法，您可以有效地从症状分析转向解决。

步骤 1：通过 CloudWatch 和 Performance Insights 进行即时指标分析

任何性能调查的第一步是量化瓶颈。AWS CloudWatch 提供诊断问题是计算密集型、I/O 密集型还是连接密集型所需的高级别指标。

关键指标调查

分析以下指标，特别关注性能下降发生前和期间的指标，并关注相关的峰值：

  1. CPU 利用率： 突然接近 100% 的峰值通常表明工作负载过重、查询计划不佳或存在大量后台任务。
  2. 读/写 IOPS 和延迟： 高延迟结合满负荷的 IOPS 表明数据库在等待存储时存在瓶颈。如果工作负载超过了预配的 IOPS (PIOPS)，或者通用 SSD (gp2/gp3) 实例耗尽了它们的突发余额，这种情况很常见。
  3. 数据库连接数： 活动连接数的急剧增加会耗尽内存或达到 max_connections 限制，导致连接失败和资源争用。
  4. 可用内存： 可用内存的快速下降或持续偏低可能表明查询缓存效率低下或进程占用了过多的内存，导致交换（这是 I/O 密集且缓慢的）。

使用 Performance Insights

对于大多数现代 RDS 引擎（PostgreSQL、MySQL、MariaDB、Oracle、SQL Server），Performance Insights (PI) 是最重要的工具。PI 以可视方式展示数据库负载 (DB Load)，让您立即看到导致峰值的原因：

  • PI 按等待状态（例如，CPU、I/O 等待、锁等待）和热门 SQL 对 DB Load 进行细分，从而即时了解瓶颈来源。

提示： 如果 DB Load 出现峰值，但大部分等待被归类为CPU，则问题是复杂的查询处理。如果等待主要是I/O，则问题是读写存储中的数据。

步骤 2：检查活动会话和等待事件

一旦指标确认了瓶颈所在（例如，高 CPU），下一步就是确定当前造成负载的“谁”或“什么”。

使用 Performance Insights，确定在性能下降期间消耗最多 DB Load 的热门 SQL。如果 PI 未启用，您必须直接连接到数据库实例。

特定于数据库的会话命令

MySQL/MariaDB

使用 SHOW PROCESSLIST 查看当前执行的查询。查找长时间运行的事务（Time 值高）或处于 Sending data 或 Locked 状态的命令。

SHOW FULL PROCESSLIST;

PostgreSQL

查询 pg_stat_activity 视图以查找活动查询及其等待事件。查找 wait_event_type 非空且 query_start 时间较长的查询。

SELECT pid, datname, usename, client_addr, application_name, backend_start,
       state, wait_event_type, wait_event, query_start, query
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY query_start ASC;

关注等待事件（例如，lock 等待事件）可立即揭示可能导致整个系统停顿的并发问题或模式锁定争用。

步骤 3：诊断和优化慢查询

通常，性能突然下降是由最近部署的更改引起的——新查询、过时的查询计划或缺失的索引。使用慢查询日志（MySQL/MariaDB）或 pg_stat_statements（PostgreSQL）结合 Performance Insights 数据来精确找出影响最大的查询。

分析执行计划

一旦确定了候选查询，就使用数据库的执行计划工具（EXPLAIN 或 EXPLAIN ANALYZE）来理解数据库如何执行该查询。

  1. 识别全表扫描： 常见的性能杀手。如果一个查询在不使用索引的情况下扫描大型表，性能将急剧下降。
  2. 检查索引使用情况： 确保数据库对 WHERE 子句、JOIN 条件和 ORDER BY 子句使用了最优索引。

示例：检查查询计划

EXPLAIN ANALYZE 
SELECT * FROM large_table WHERE column_a = 'value' AND column_b > 100;

如果计划显示索引利用率不高，则首要的解决方案通常是创建新的、有针对性的索引。对于关键的、长时间运行的查询，可以考虑简化连接或拆分复杂操作。

最佳实践： 查询优化是最频繁的长期解决方案。优先优化导致最高 I/O 或 CPU 负载的查询。

步骤 4：验证实例和参数组配置

如果负载看起来正常，但资源（如内存或连接数）已满，问题可能是配置不足或参数配置不佳。

实例大小和类型

  1. T 系列信用检查： 如果使用突发实例（T 系列），请在 CloudWatch 中检查 CPU 信用余额。如果余额降至零，实例将被限速，导致性能急剧下降。如果需要持续负载，请升级到固定性能类（M、R 或 C）。
  2. 资源限制： 检查实例类是否为当前工作负载配置文件提供了足够的 RAM 和 IOPS。如果数据库频繁发生交换或达到 PIOPS 限制，则需要升级（垂直扩展）。

参数组审查

验证关键参数，这些参数通常根据实例大小自动缩放，但可能已被覆盖或设置得过低：

  • max_connections：确保此参数（从实例内存派生）足以应对峰值负载。
  • innodb_buffer_pool_size (MySQL) 或 shared_buffers (PostgreSQL)：此内存区域对于缓存数据至关重要。如果设置过小，数据库将严重依赖缓慢的磁盘 I/O。

步骤 5：审查系统维护和次要操作

有时，性能下降是暂时的，由自动系统任务或后台复制进程引起。

自动备份和维护窗口

检查 RDS 控制台中的维护窗口和备份窗口设置。自动快照可能会引入临时 I/O 延迟，尤其是在工作负载已经很高的情况下。如果性能下降与备份窗口精确对应，请考虑将窗口移至不太关键的时间，或确保在备份期间分配了足够的 PIOPS 来处理负载。

复制延迟

如果应用程序依赖于只读副本，主实例的性能突然下降会导致严重的复制延迟。高复制延迟表明主实例无法足够快地处理更改，这通常会指向步骤 3（慢查询）或步骤 4（资源不足）中发现的问题。

在 CloudWatch 中监控 ReplicaLag 指标。如果延迟很大，请将故障排除工作重新集中在主实例的事务速率和优化上。

二进制日志记录（WAL 归档）

在高事务环境中，过多的二进制日志记录（PostgreSQL 中的 WAL 归档）用于复制或时间点恢复可能会加剧 I/O 压力。如果已确认 I/O 延迟是瓶颈，请确保二进制日志记录保留和文件大小参数已针对工作负载进行了优化。

结论

排除 RDS 性能突然下降的故障需要一种严谨的方法，系统地从通用指标（步骤 1）到具体代码分析（步骤 3），最后确认配置限制（步骤 4 和 5）。通过利用 AWS Performance Insights 和标准的数据库诊断命令，团队可以显著缩短平均解决时间 (MTTR)，并恢复数据库的最佳功能。持续监控 DB Load、I/O 延迟和关键系统参数是防止未来意外性能下降的最佳防御措施。