EC2性能问题

Question

这周刚花了两天时间来解决离岸团队记录的EC2中的开发问题。

在EC2中的多个Dev实例中运行apache/tomcat版本7.0.21已经几周了，没有问题。

然后是D3 env中的主要性能问题。第一次在岸上重新运行脚本没有问题。

同样，D3 env中的离岸记录缺陷，这一次他们在D2克隆中运行脚本没有问题。上午再次在D3上运行脚本，这一次出现了重大问题。

有一种感觉，那是基础设施，但无法证明。

调优servlet容器查看垃圾收集、堆、jdbc池中的沙箱env，没有什么问题。

然后在D3克隆映像中传递脚本。所有记录的缺陷都通过了。我们什么都没改变。

它看起来像是一个EC2问题，无论是在Xen、网络上还是在RDS上。不知道那是什么。

当你盲目飞行时，你怎么能在云中隔离故障。由于没有基础设施的可见性，您从哪里开始？

有人有类似的问题吗？

可以监视EC2基础设施吗？

Answer 1

Perry，听起来您似乎正确地诊断了这个问题( EC2上的虚假/随机/意外行为几乎总是降级主机硬件的副作用)--您可以确认的唯一方法是将其发布到EC2论坛或打开支持票，并要求他们调查EC2团队何时可以确认/拒绝故障硬件。

解决办法，无论您是否得到确认，总是关闭和重新启动您的VM，这将把它放在不同的硬件。(您可以定期在EC2论坛上看到这一点)。

在将来，我将使它成为解决EC2上完全随机问题的第一步；重新启动一个实例。

在EC2上仍然无法获得底层硬件状态的实时警报，即使是在硬件失败时发出的为数不多的电子邮件通知似乎也是随机的，因为硬件仍然可能出现故障，而且您永远不会收到其中一封监控邮件。

您可以尝试将监视服务指向您的单个实例，如，但这些都是简单的ping测试，我不知道这些测试是否适合您。

或者，如果您可以将所看到的故障缩小到随机失败的特定事物(例如，当硬件开始失败时在EC2上运行的某个操作)，您可以编写一个系统脚本/cron作业，它每隔1分钟或10分钟运行一次准确的服务，并报告一个错误。

这是一种煤矿中的金丝雀式方法，没有什么科学或精确的方法，但它可能会有所帮助，让你在用户之前就能发现问题。