诊断（和避免）前 3 个 AWS EC2 问题

有数量惊人的企业围绕 Amazon Web Services 的云产品构建其核心应用程序，例如他们的弹性计算云 (EC2)。 2010 年，亚马逊报告的 EC2 增长率为 35%。从创建用于制药研究的按需超级计算集群到加强音乐识别应用程序 Shazam 的后端，它已被用于各种用途。

EC2 对于希望在不购买物理基础设施的情况下组装大量计算能力的业务 IT 团队以及必须为客户需求的定期高峰做好准备的业务 IT 团队非常有用。话虽如此，EC2 是一个与其他任何工具一样的工具。它很容易被滥用或错误配置，如果发生这种情况，您的业务可能无处可扩展。以下是如何在您的应用程序开始崩溃之前避免最常见的 EC2 错误。

1.令人困惑的存储延迟

Amazon EC2 的存储卷（称为 Elastic Block Storage，或 EBS）有两种形式。标准卷以与标准桌面硬盘驱动器大致相同的速率提供数据，但预配置卷旨在以更快的速度提供数据。如果您需要高达 4,000 IOPS（每秒输入/输出操作）的吞吐量，Provisioned 卷可以为您提供 - 假设您跳过几个环节。

例如，正在使用的实例必须与您需要的 IOPS 数量兼容。您需要将块大小设置为 16KB 或更少，并且这些块必须至少被访问过一次。如果即将执行备份，您的卷会变慢。最后，Amazon EC2 显然不包含一个工具，可以为您提供来自给定卷的实时 IOPS 数据（尽管这可以使用第三方监控应用程序计算）。

最后一个限制可能会导致一些困难。可能会发生以下情况：

• IOPS 在管理员不知情的情况下增加，直到达到某个卷的阈值，
• 操作随后开始排队，
• 整个应用程序随后会受到 EBS 的速率限制，
• 应用程序完全失败。

解决此问题意味着寻找其他方法来跟踪 IOPS。 VolumeQueueLength 指标跟踪待处理 I/O 请求的数量。如果您发现您的 EBS 卷变慢，并且您发现关联的 VolumeQueueLength 很高，这可能表明 IOPS 存在问题。

2.空闲的 EC2 实例

亚马逊现在可以对 EC2 实例的使用按秒收费。对于某些企业（例如，需要一次使用不到两分钟的灵活容量的企业）来说，这是一笔划算的交易。在其他情况下，它可能代表浪费金钱的缓慢涓涓细流。剩余的测试环境、性能不佳的应用程序和其他用例会导致未充分利用的 EC2 实例。你如何追踪他们？

指标是解决这个问题的一种方法，但它们是一个不断变化的目标。例如，不同的应用程序使用不同数量的 CPU，因此您不能简单地查看 CPU 使用率来了解表现不佳的地方。您需要淘汰所有使用指标都较低的实例，其中“低”意味着“低于所有 EC2 实例的基准利用率”。使用指标普遍较低的实例可以停止运行或合并。

3. EC2 内存泄漏

EC2 实例可能会耗尽内存。由于某些 EC2 实例不包含交换卷，关联的应用程序将无法在分配内存的同时释放内存。由于这种情况发生在应用程序使用量特别大的时候，因此 EC2 可能会在它经历峰值工作负载时立即冻结——或多或少完全违背了购买 EC2 实例的初衷。

与 IOPS 的情况一样，为了找出哪些应用程序使用了过多内存，很难在 EC2 的幕后查看。虽然 EC2 会自动终止占用内存的进程，但最好不要首先终止这些进程。还可以添加更多 EC2 实例以用作交换卷，或者在重要进程被终止时用作故障转移。然而，添加这些实例是昂贵的。有更好的方法。

使用 AppNeta 监控 AWS EC2

有一点很清楚——AWS EC2 实例没有为管理员提供许多用于查看性能的内置工具。智能编程、故障转移规划和手动监控实施只能带您到此为止。 AppNeta 为 AWS 提供了一种性能可见性解决方案，让管理员可以主动查找错误。

看一看 Amazon SDN 的内部（是的，它实际上是可能的）并立即清晰地了解瓶颈和减速。如需更多信息，请立即试用我们的演示。