AWS EC2资源利用

Question

想知道其他人是如何看待AWS EC2实例中的追索权利用的。例如，我正在尝试“适当大小”我们的许多过度配置的实例，使其具有正确的实例类型/性能规范。在这样做的过程中，我一直在调整到实例大小，这些实例大小可能对给定的工作负载具有80%+内存利用率。

其想法是，在处理云实例时，追索权利用率与使用裸金属硬件或on虚拟化/超级外观时不同。当使用裸金属/ or服务器/超级管理员时，管理员通常会查看资源利用率，希望看到内存利用率低于50%或其他什么；或者换句话说，80%+内存利用率看起来是一件坏事，管理员可能会分配更多的内存以降低基线利用率。这样的想法是，在流量或工作负载需求增加的时候，服务器将能够处理它，而不会减慢/显著的性能损失。

但是，在使用云实例时，您需要按需使用的资源，您不再在购买物理硬件时预先支付资源-所以理论上您希望使用大部分内存分配作为您的基线，以优化实例类型/大小的成本节约。此外，资源是可存储的，因此即使在达到100%利用率时，也不会看到性能下降或挂起，因此，高内存利用率是调整通常使用相同内存量的工作负载的理想情况。换句话说，对于处于80%-95%内存利用率之间的工作负载，95%的时间。

我想知道这种想法在任何人看来是否有缺陷。使用EC2实例的管理员是否仍然试图保持较低的内存利用率？对我来说，这听起来像是过时的习惯，不再适用。而且，只要cpu在分配的基线%以下累积积分，而内存在大多数情况下都保持在100%以下，那么这是在保持相同性能的同时最小化实例成本的理想设置。有什么想法？

Answer 1

我大体上同意你所写的。您需要相当高的CPU和内存分配，一旦接近极限，自动缩放添加容量通常是最好的方法。您可以为诸如磁盘缓存这样的事情留出一些空闲的RAM，特别是因为EBS是网络磁盘。

虽然T系列实例的基线是服务器CPU容量的一个百分比，但它们可以在某种程度上突发CPU。T3无限意味着你只需支付更高比例的CPU，但你不能获得更多的核心或内存。据我所知，其他实例类型没有突发容量。调整实例的大小是相当简单的，尽管有几分钟的停机时间，但是如果它们是web服务器，将它们放在负载均衡器后面可以帮助消除停机时间。

我有一个过度供应的t3a.nano。它使用Nginx、MySQL、PHP、Dropbox克隆类型工具、Docker中的密码管理器和其他部件运行五个低容量Wordpress网站。这是一个CPU内核的5%，0.5GB内存，0.5GB交换和12‘s磁盘。目前它有38 of的RAM空闲，183 of作为缓存，因此实际上它使用的是291 of的RAM。这是AWS出售的最小服务器，而不是ARM / Graviton。如果有一个带256 go的pico实例，我可以试一试！

Answer 2

我会看计算机优化器的建议。它应该为您提供几个选项来根据观察到的工作负载来调整EC2实例的大小。