我目前在AWS中使用内存优化的DB类（8个CPU），因为我们的应用程序中的一些推送通知会导致CPU利用率飙升，但99%的时间CPU利用率约为10%，因此大部分时间都不需要8个CPU。我是否能够在Burstable示例上部署更少的CPU，并在有那些高流量推送通知时调整CPU？可突发示例如何工作？
nfs0ujit1#
我不会为任何生产流量选择可爆发示例。可突发示例每小时累积多个“性能信用”。当流量增加并且您需要大量资源时，可以使用这些配额。当信用用完时，示例仍然运行，但只有“基线性能”，坦率地说，这不足以处理生产流量。我见过许多用户试图通过使用T系列示例类型来节省成本。他们通常很失望，因为他们低估了自己对资源的需求。它们最终会过快地消耗其突发信用，然后过于频繁地以基线性能级别运行。我只在CI测试服务器或开发中使用可突发示例。这些示例通常在大部分时间都处于空闲状态，并积累了良好的性能信用级别。他们短暂地使用这些信用，然后回到空闲的活动水平。注意：还有“Unlimited”选项，T3示例默认使用该选项。这改变了突发性能的性质。您可以在长时间内获得更高的CPU性能，但最终会为此付出更多。要了解详细信息，请仔细阅读https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html。您也可以查看Aurora Serverless。这应该会自动扩展更多的复制副本示例以响应流量的增加，这应该会为您提供更多的CPU容量。您只需为您使用的示例付费。这是理论，但我不能从经验中说话，因为我没有使用或测试Aurora Serverless。它的工作效果和经济性取决于应用程序的工作负载。我所能建议的就是给予一试。哪种示例类型和选项最适合您，在很大程度上取决于特定应用程序的流量模式。它是否具有一致的负载或周期性负载（例如，在工作时间高负载，但在夜间较低）？它主要是CPU绑定、内存绑定、I/O绑定还是网络绑定？在选择最佳示例类型之前，您需要了解应用程序的资源需求。
vmdwslir2#
我相信大多数RDBMS，特别是MySQL，只能“垂直”扩展，在这个意义上，你不能动态地添加/删除CPU资源来处理突发的读/写。也许你可以创建一个“通知/扇出”服务，它可以更容易地动态扩展和缩小，使用DynamoDB或AWS SNS。这样，您的主数据库可以避免所有这些流量，反过来，您可以为RDS使用更便宜的EC2示例。
2条答案
按热度按时间nfs0ujit1#
我不会为任何生产流量选择可爆发示例。
可突发示例每小时累积多个“性能信用”。当流量增加并且您需要大量资源时，可以使用这些配额。当信用用完时，示例仍然运行，但只有“基线性能”，坦率地说，这不足以处理生产流量。
我见过许多用户试图通过使用T系列示例类型来节省成本。他们通常很失望，因为他们低估了自己对资源的需求。它们最终会过快地消耗其突发信用，然后过于频繁地以基线性能级别运行。
我只在CI测试服务器或开发中使用可突发示例。这些示例通常在大部分时间都处于空闲状态，并积累了良好的性能信用级别。他们短暂地使用这些信用，然后回到空闲的活动水平。
注意：还有“Unlimited”选项，T3示例默认使用该选项。这改变了突发性能的性质。您可以在长时间内获得更高的CPU性能，但最终会为此付出更多。要了解详细信息，请仔细阅读https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html。
您也可以查看Aurora Serverless。这应该会自动扩展更多的复制副本示例以响应流量的增加，这应该会为您提供更多的CPU容量。您只需为您使用的示例付费。这是理论，但我不能从经验中说话，因为我没有使用或测试Aurora Serverless。它的工作效果和经济性取决于应用程序的工作负载。我所能建议的就是给予一试。
哪种示例类型和选项最适合您，在很大程度上取决于特定应用程序的流量模式。它是否具有一致的负载或周期性负载（例如，在工作时间高负载，但在夜间较低）？它主要是CPU绑定、内存绑定、I/O绑定还是网络绑定？在选择最佳示例类型之前，您需要了解应用程序的资源需求。
vmdwslir2#
我相信大多数RDBMS，特别是MySQL，只能“垂直”扩展，在这个意义上，你不能动态地添加/删除CPU资源来处理突发的读/写。
也许你可以创建一个“通知/扇出”服务，它可以更容易地动态扩展和缩小，使用DynamoDB或AWS SNS。这样，您的主数据库可以避免所有这些流量，反过来，您可以为RDS使用更便宜的EC2示例。