为何未达gp3磁盘基准用量时EBSByteBalance%与EBSIOBalance%仍耗尽？

首先明确：EBSByteBalance%和EBSIOBalance%反映的是gp3卷的突发信用剩余量。当卷的实际IO吞吐量/IOPS超过基准值时，会消耗突发信用，剩余百分比下降；当实际用量低于基准值时，会积累信用，剩余百分比上升。你的情况是实际业务用量未达基准，但指标持续下降，核心原因是未统计到的IO消耗在占用信用，或是实例规格限制导致的信用异常消耗：

• RDS后台操作的隐性IO消耗：
  PostgreSQL RDS的后台操作会产生大量IO，这些不会被常规业务监控统计到：

  • WAL日志的写入与归档：PostgreSQL会持续写入WAL日志以保证数据一致性，即使业务负载低，WAL的同步、归档操作也会占用IOPS和吞吐量。
  • 自动维护操作：比如自动VACUUM清理旧数据、ANALYZE更新统计信息、RDS的自动快照创建、增量备份同步，这些操作都会消耗卷的IO资源。
  • 系统层面的IO：比如RDS实例的系统日志写入、临时文件操作、数据库元数据的更新等。

• db.t3.micro实例的性能限制：
  db.t3.micro是突发性能实例，它的CPU、网络和IO都有严格上限：
  即使gp3卷配置了3000 IOPS的基准，db.t3.micro实例的最大IOPS上限仅为1000左右，吞吐量上限为125 MiBps。当业务IO达到实例的IO上限时，虽然低于gp3卷的基准，但EBS卷的IO调度会因实例限制出现队列等待，间接触发信用消耗逻辑。

• 信用计算的时间窗口偏差：
  EBS的信用计算按5分钟窗口统计，你监控的实际用量可能是平均数值，但在某个短时间窗口内（比如峰值瞬间），IO吞吐量或IOPS可能超过了基准值，导致信用被消耗，而平均用量看起来未达基准。

• 扩展监控范围：在CloudWatch中添加EBSReadIOPS、EBSWriteIOPS、EBSReadBytes、EBSWriteBytes的5分钟峰值监控，查看是否有瞬间超基准的情况；同时监控PostgreSQLWALWriteIOPS、PostgreSQLVACUUMIOPS等RDS专属指标，确认后台操作的IO消耗。
• 切换实例规格：如果业务需要稳定的IO性能，建议将实例从db.t3.micro切换到非突发性能实例（如db.t3.small或db.m5.large），解除实例层面的IO限制，让gp3卷的基准性能正常发挥。
• 调整配置与参数：如果后台IO确实持续较高，可以考虑降低gp3的基准IOPS配置（若不需要3000），或调整PostgreSQL参数（如WAL保留时间、自动VACUUM频率）来减少后台IO。

内容的提问来源于stack exchange，提问作者fguillen