我们在Ubuntu 9.10 x64 xlarge Amazon EC2实例上运行LAMP + memcached。 这台服务器每秒处理几百个请求，其中大约60％是静态的，剩下的都以某种方式与mysql和/或memcached交互。 该服务器已经遭受了两个可能相关的性能问题，并且已经certificate难以诊断。 除非另有说明，否则以下所有统计数据均与CloudWatch，munin或vmstat / iostat / top收集在一起。
第一个问题是每隔几分钟就会发生一次高度的爱荷华州经常发生的尖峰，在此期间，大多数apache进程都会在所有未挂起的情况下同时处理约10-30秒。 在此期间没有增加的磁盘或networking负载，磁盘队列保持低电平，不会进行交换等。
更严重的是，在高峰时段，服务器有时突然出现性能急剧下降的情况，服务请求数量减less了1/3。 一旦开始，这个性能下降可以持续2到8小时，然后再突然恢复到全部性能。 当发生这种情况时，就好像系统停止了任何事情。 CPU利用率，磁盘负载和networking负载（由CloudWatch报告）均按比例下降，但没有磁盘争用。 磁盘队列和吞吐量都下降，并且始终低于最大值，特别是在这些下降过程中。 编辑：这个问题已经解决。 Apache耗尽了工作进程，出于某种原因决定这是完全崩溃性能的一个很好的理由，即使那些工作正常的进程也是如此。
networking读取是个例外，它保持与以前一样高，表示服务器仍然像以前一样以高容量被访问。 如果我们尝试在发生这种情况时自己联系服务器，则服务器速度非常慢，并且通常会在请求被服务之前断开连接。 需要注意的是，无论内存使用率还是CPU利用率，在任何时候都不是特别高的，无论性能是否正在下降：CPU％很less超过10％，磁盘没有满或拥塞。 我们还没有能够收集这些下跌期间掉期performance的数据，但正在尝试这样做。
事实上，我们对可能引起这些神秘问题的想法不甚了解，并且越来越担心这可能是EC2本身的一个问题（或称错误）。 事实上，当我们的stream量达到峰值时，总是出现大量的跌落事件（尽pipe这并不意味着服务器已经接近最大可用资源）并不是简单的巧合。
所有MySQL数据库和日志都托pipe在EBS卷上，所有静态内容都托pipe在单独的不同EBS卷上。 Apache服务每秒160-240个请求，MySQL 180-200每秒查询，caching查询速度约为0％，memcached命中率约为90％。 平均负载平均在3左右。禁用Apache访问日志logging以最小化磁盘访问。
最有可能（正如你所指出的，你发现第二个问题的解决scheme）这些问题是configuration或以其他方式为基础。 EC2 / EBS /任何云技术都不是这个的根源。 这些问题在任何情况下都会违背迄今为止收到的答案。
另外 – 亚马逊提供了一个SLA。 虽然极less有一些资源可能引起争议，但情况仍然很小。 但是，这是不太可能考虑你目前的使用情况。 我将继续对争论的各个方面进行诊断性研究，并与Amazon Web Services的技术团队进行交stream。 另外检查他们的论坛，因为那里通常是非常有知识的人。 你可能知道论坛，但以防万一 – 检查他们在这里： https : //forums.aws.amazon.com/index.jspa
另外，从架构的angular度来看，您是否想过在多个EC2实例之间分配这个负载并进行负载平衡？ 这是一个解决其中一些问题的选项。 也就是说，从你正在讨论的架构来看，如果你将一些稍微不够强大的实例分配并分配工作，总体上可能会更好。 另一个好处是，如果您的网站/服务继续增长，那么您就可以横向扩展，而不是垂直扩展，当然后者是有限的。
首先也很抱歉，您的网站负载存在严重问题，据我所知，所有这些都应在SLA关于应用程序可用性和性能的政策中列出，您应该有权获得信用。
使用共享公共云作为user37899已经评论是不是理想的平台，如果这是一个关键的应用程序和密集的操作。 共享的故事不仅仅是你不能确定你的程序在哪里运行，除此之外，你的性能也受到网格上的其他客户的影响。 该存储很可能是该特定网格上的共享资源，这会导致性能下降。
Amazon x64 xLarge部署应该正确地指定，但是正如上面提到的磁盘资源，虽然由它们的卷和RAIDconfiguration仍然从共享池访问。
我有兴趣了解一些更多的东西，以及其他一些性能计数器和数据库架构，以帮助解决这个问题。 虽然听起来对我来说更好的解决scheme是至less将您的数据库层裸机或私有云利用自己的专用硬件。
随时给我一个笔记我可以聊天，祝你好运。
由于EC2是共享主机环境（您的主机与其他主机共享相同的硬件），因此您可以在I / O操作中看到很大的变化。 EBS卷基本上是NAS，并与networkingstream量共享相同的NIC。 每个物理主机只有1Gb连接到主干。 因此，您不仅与其他客户的networking操作竞争，还会与您的磁盘和您的磁盘进行networking争用。 在实践中，networking争夺通常不是一个问题，除非你与其他许多高stream量的客户共享这个盒子。 你可以通过使用更大的实例来解决其中的一些问题（更大的实例占用更大的比例，因此共享资源更less）。
你在高峰期和在这些问题期间遇到了什么样的问题？ （sar -d tps列）
这段时间你偷的时间是多less？ （iostat -x 1或sar -u）。
您可以通过将多个EBS卷一起软件RAID来增加您的IOP容量，这将有助于您的Iowait时间。 这听起来很糟糕，但它确实有效。 这不会解决networking争用问题，但是随着你的stream量，我非常怀疑你是否在饱和链路。 但另一位顾客可能会给你带来一些痛苦。
有时，不幸的是，这种types的问题的一个简单的解决scheme是简单地重新绑定实例。 它可能会出现在不同的共享客户的主机上。 对于EC2客户来说，这是一个普遍的做法，可以创build实例，运行一些基准，如果对结果不满意，可以重新考虑。
另一个build议是将您的Web和数据库层分成不同的服务器。 带有web / db的单个服务器由于许多原因通常是个坏主意，在这种情况下可能使得诊断瓶颈变得更加困难。