如何对 Amazon RDS for PostgreSQL 中的 DiskQueueDepth 增加问题进行故障排除？

简短描述

DiskQueueDepth 是指应用程序已提交但尚未发送到存储设备的输入和输出 (I/O) 请求的数量。由于磁盘或存储正忙于处理其他请求，这些请求处于待处理状态。

高 DiskQueueDepth 表示 I/O 请求的增长速度超过了存储系统的处理能力。Amazon RDS 以一分钟为间隔报告此指标的平均值。最佳做法是将每 1000 个可用 IOPS 的队列长度目标设定为 1。

**注意：**要衡量 I/O 性能，请检查实例的吞吐量和 I/O 操作次数。

解决方法

要对 Amazon RDS for PostgreSQL 中的 DiskQueueDepth 增加问题进行故障排除，请完成以下操作：

识别高 DiskQueueDepth

要识别高 DiskQueueDepth，请检查以下内容：

• 当遇到性能问题时，请检查您的 Amazon CloudWatch 指标。查看 DiskQueueDepth 指标是否出现高于正常水平的峰值。如果 DiskQueueDepth 长时间持续偏高，则查询在运行前的等待时间会更长。
• 检查您的实例类型限制。确认 ReadIOPS、WriteIOPS、ReadThroughput 和 WriteThroughput 指标是否达到其实例类型限制。
• 检查您的 ReadThroughput 和 WriteThroughput 指标。CloudWatch 以每秒字节为单位呈现这些数据，为了更清晰地解读，请将这些值转换为 MB/s 或 GB/s。要确定是否已达到分配的吞吐量限制，请对同一时间段内的这两个指标求和。有关分配给实例的吞吐量的详细信息，请参阅 Amazon RDS 实例类型文档。
• 查看您的 EBSByteBalance% 指标。如果 EBSByteBalance% 等于或接近零，则表示实例耗用了较高的吞吐量。此外，字节余额为零表示带宽出现节流。

检查存储类型和大小

要检查您的存储类型和大小，请执行以下操作：

• 优化您的工作负载。探索可用选项来调整和提高工作负载的效率。
• 对于通用型 SSD (gp2)，请确保您的存储大小具有足够的基准 IOPS 和吞吐量。
• 要获得更多 IOPS 或预置的 gp3、io1 和 io2，请调整您的工作负载或扩展到具有更高 CPU、内存和 I/O 容量的更大实例。

检查流量是否突然增加

数据库活动的意外峰值可能会导致 DiskQueueDepth 增加。要识别连接中的峰值，请执行以下操作：

• 查看 Amazon CloudWatch 指标中的 DatabaseConnections 图表。并发连接过多可能会导致大量的读写操作。
• 每 1000 个可用 IOPS 的队列长度应为 1。（这是通用型 SSD 卷的基准值，也是预调配 IOPS SSD 卷的预置量。）
• 监控应用程序性能并根据您的需求进行调整。

检查是否存在微爆问题

如果您的实例未达到其吞吐量或 IOPS 限制，但延迟很高且队列长度很长，则您的实例可能会发生微爆。要解决此问题，请参阅如何确定我的 Amazon EBS 卷是否处于微爆状态，并防止这种情况发生？此外，请确保启用增强监控，然后将粒度设置为 1 秒，从而确定是否为微爆问题。

优化不良查询

要优化不良查询，请执行以下操作：

• 要查看在 DiskQueueDepth 较高时间段内运行的查询类型，请使用性能详情。
• 要生成查询运行计划，请使用 EXPLAIN 来确定优化机会。有关详细信息，请参阅 PostgreSQL 网站上的 EXPLAIN。
• 检查是否存在可能导致 I/O 过多的全表扫描、低效联接或索引缺失问题。