了解 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 数据库实例类也有 I/O 和吞吐量限制，在我们的示例中仅为 10 MB/s 左右。我没有意识到这一点，并且很难在网上找到这些性能数据。但对于任何想知道未来的人，可以在这里找到它们： https: //instances.vantage.sh/rds/ 他们还确认，在资源限制下，RDS 实例可能会重新启动，并将这视为我们所目睹的行为的明显解释。

所以这个谜团在我们的案例中得到了解答。希望这对将来的人有帮助