AWS RDS 优化内存与突发实例

Question

我目前在 AWS 中使用内存优化的数据库类（8 个 CPU），因为我们应用程序中的一些推送通知导致 CPU 利用率飙升，但 99% 的时间 CPU 利用率约为 10%，因此实际上并不最需要 8 个 CPU的时间。

我是否能够在突发实例上部署更少的 CPU，并在出现大流量推送通知时调整 CPU？

突发实例如何工作？

Answer 1

我不会为任何生产流量选择可突发实例。

可突发实例每小时累积一定数量的“性能积分”。当流量增加并且您需要大量资源时，可能会消耗这些积分。当积分用完时，实例仍然运行，但只有“基准性能”，坦率地说，不足以处理生产流量。

我看到许多用户尝试通过使用 T 系列实例类型来节省成本。他们通常非常失望，因为他们低估了自己对资源的需求。他们最终会过快地消耗掉突发积分，然后过于频繁地在基准性能水平上运行。

我只会将可突发实例用于 CI 测试服务器或开发。这些实例通常大部分时间都处于空闲状态，并积累了良好的性能积分。他们会短暂使用这些积分，然后返回到闲置的活动水平。

注意：还有“无限制”选项，T3 实例默认使用该选项。这改变了突发性能的性质。您可以长时间获得更高的 CPU 性能，但最终会为此付出更多代价。要了解详细信息，请仔细阅读https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html。

您还可以研究 Aurora Serverless。这应该会自动扩展更多副本实例以响应流量增加，从而为您提供更多 CPU 容量。您只需为您使用的实例付费。这是理论，但我不能凭经验说话，因为我还没有使用或测试过 Aurora Serverless。它的工作效果如何以及对您来说有多经济取决于您的应用程序的工作负载。我所能建议的就是尝试一下。

哪种实例类型和选项最适合您很大程度上取决于您的特定应用程序的流量模式。是否具有一致的负载，或周期性负载（例如，工作时间负载高，但夜间负载较少）？主要是受 CPU 限制、内存限制、I/O 限制还是网络限制？您需要先了解应用程序的资源需求，然后才能选择最佳实例类型。