了解 AWS RDS gp3 卷中的 EBSByteBalance%

Question

我正在对 AWS RDS Postgres 实例进行故障排除，该实例在过去几天内被 AWS 重启了好几次，很可能是由于资源限制。这是一个测试数据库，通常不会做太多事情，但我们最近给它增加了一些更高的负载。我发现数据库的 EBS 卷（200GB gp3）耗尽了其吞吐量信用，并且数据库重启的时间与 EBSByteBalance% 指标达到零的时间非常吻合。然后，当数据库重新启动时，该卷显然会获得一组新的突发信用，如下面的屏幕截图所示：

由于我们减轻了数据库的负载，积分现在下降得稍微慢了一点，但仍在下降。当我查看当前的读写吞吐量指标时，它们似乎总计约为 5 到 7 MiB/s，偶尔会出现峰值：

根据此处找到的信息Amazon RDS 数据库实例存储400gb 以下 gp3 卷的基准吞吐量应为 125MiB/s。那么有人能帮我解释一下为什么 EBSByteBalance% 指标在这种情况下不断下降吗？谢谢！

Answer 1

好的，我按照@Tim的建议联系了AWS支持。他们澄清了以下内容：

请注意，指标“EBSIOBalance%”和“EBSByteBalance%”是实例类指标。请注意，GP3 卷不使用突发性能，因此指标指的是实例类突发性能而不是卷。EBSIOBalance% 监控实例 I/O 突发存储桶，EBSByteBalance% 监控实例字节突发存储桶。这些指标提供有关各自突发存储桶中剩余的 I/O 或字节信用百分比的信息。指标以百分比表示，其中 100% 表示实例已累积最大信用数。

因此，T4G DB 实例类也存在 I/O 和吞吐量限制，在我们的例子中，该限制仅为 10 MB/s 左右。我当时并不知道这一点，在网上很难找到这些性能数据。但对于将来想知道的人来说，可以在这里找到它们：https://instances.vantage.sh/rds/ 他们还确认，在资源限制下，RDS 实例可能会重新启动，并将此视为我们所看到的行为的明显解释。

所以我们的谜题已经解开了。希望这对以后的某人有所帮助