想知道其他人如何看待 AWS EC2 实例中的资源利用率。例如，我试图将许多过度配置的实例“调整大小”，使其符合正确的实例类型/性能规格。在此过程中，我一直在缩小实例大小，使其对于给定的工作负载可能具有 80% 以上的内存利用率。
其理念是，使用云实例时的资源利用率与使用裸机硬件或本地虚拟化/虚拟机管理程序时的资源利用率不同。使用裸机/本地服务器/虚拟机管理程序时，管理员通常会查看资源利用率，并希望内存低于 50% 或任何其他水平；换句话说，80% 以上的内存利用率看起来是一件坏事，管理员可能会分配更多内存以降低基线利用率。其理念是，在流量或工作负载需求增加时，服务器将能够处理它，而不会减慢/明显的性能损失。
但是，在使用云实例时，您需要按需支付已使用的资源费用，而不再需要预先支付购买物理硬件的费用 - 因此从理论上讲，您希望将大部分内存分配用作基准，以优化实例类型/大小的成本节省。此外，资源是可突发的，因此即使有时利用率达到 100%，也不会看到性能下降或挂断，因此高内存利用率是调整通常使用相同内存量的工作负载的理想情况。换句话说，对于 95% 的时间内存利用率在 80%-95% 之间的工作负载来说。
我想知道是否有人认为这种想法是错误的。使用 EC2 实例的管理员是否仍试图保持较低的内存利用率？对我来说，这听起来像是过时的习惯，不再适用。只要您的 CPU 保持在分配的基准百分比以下以累积信用，并且您的内存在大多数时间内保持在 100% 以下，那么这就是在保持相同性能的同时最小化实例成本的理想设置。有什么想法吗？
答案1
我大体上同意你的观点。你需要相当高的 CPU 和内存分配，一旦接近极限，自动扩展以增加容量通常是最好的方法。你应该为磁盘缓存等留出一些可用 RAM，特别是因为 EBS 是网络磁盘。
T 系列实例可能会在一定程度上导致 CPU 爆发，尽管它们的基准是服务器 CPU 容量的百分比。T3 无限制意味着您可以简单地支付更高比例的 CPU，但无法获得更多内核或 RAM。据我所知，其他实例类型没有爆发容量。调整实例大小相当简单，尽管会有几分钟的停机时间，但如果它们是 Web 服务器，将它们放在负载均衡器后面可以帮助消除停机时间。
我有一个配置过多的 t3a.nano。它运行着五个低容量的 Wordpress 网站，其中有 Nginx、MySQL、PHP、Dropbox 克隆类型工具、Docker 中的密码管理器和其他零碎的东西。这相当于 5% 的 CPU 核心、0.5GB RAM、0.5GB 交换和 12GB 磁盘。目前它有 38MB 的可用 RAM，183MB 作为缓存，因此实际上它使用了 291MB 的 RAM。这是 AWS 销售的最小服务器，除了 ARM/Graviton 实例之外。如果有 256MB RAM 的 pico 实例，我可能会试一试！
答案2
我会查看 Compute Optimizer 的建议。它应该会为您提供一些选项，以便根据观察到的工作负载调整 EC2 实例的大小。