我们在 Ubuntu 9.10 x64 xlarge Amazon EC2 实例上运行 LAMP+memcached。此服务器每秒处理数百个请求，其中约 60% 是静态的，其余的都以某种方式与 mysql 和/或 memcached 交互。此服务器一直受到两个可能相关且难以诊断的性能问题的影响。除非另有说明，否则以下所有统计数据均使用 CloudWatch、munin 或 vmstat/iostat/top 收集。
第一个问题是每隔几分钟就会出现高 iowait 的规律峰值，在此期间大多数 apache 进程同时 iowait 大约 10-30 秒，然后全部解除挂起。在此期间没有增加磁盘或网络负载，磁盘队列保持低位，没有进行交换等。
更严重的是，在高峰时段，服务器有时会突然出现性能大幅下降，服务请求下降到之前水平的约 1/3。一旦开始，这种性能下降可能会持续 2 到 8 小时，然后突然恢复到最佳性能。当这种情况发生时，系统就好像停止了一切。CPU 利用率、磁盘负载和网络负载（由 CloudWatch 报告）同时按比例下降，但没有磁盘争用。磁盘队列和吞吐量都下降，并且始终远低于最大值，尤其是在这些下降期间。编辑：该问题已解决。Apache 的工作进程已经耗尽，并且由于某种原因，它认为这是一个导致性能彻底崩溃的充分理由，即使对于那些运行良好的进程也是如此。
例外是网络读取，它仍然像以前一样高，表明服务器的访问量仍然和以前一样大。如果我们在这种情况发生时尝试自己联系服务器，服务器会非常慢，并且经常在请求得到服务之前就断开连接。应该注意的是，无论性能是否下降，内存使用率或 CPU 利用率在任何时候都不会特别高：CPU% 很少超过 10%，磁盘没有满或拥塞。我们尚未能够在这些下降期间收集有关交换性能的数据，但正在尝试这样做。
事实上，我们对于导致这些神秘问题的原因已经没有什么想法了，而且越来越担心这可能是 EC2 本身的问题（或缺陷）。当我们的流量达到峰值时，流量似乎总是大幅下降（但这并不意味着服务器即将耗尽其可用资源），这不可能只是巧合。
所有 MySQL 数据库和日志都托管在 EBS 卷上，所有静态内容都托管在单独的不同 EBS 卷上。Apache 每秒处理 160-240 个请求，MySQL 每秒处理 180-200 个查询，慢查询约 0%，memcached 命中率约 90%。平均负载往往徘徊在 3 左右。Apache 访问日志记录已禁用，以最大限度地减少磁盘访问。
答案1
由于 EC2 是共享托管环境（您的主机与其他主机共享相同的硬件），因此您可以看到 I/O 操作存在相当大的差异。EBS 卷本质上是 NAS，并与网络流量共享相同的 NIC。每个物理主机与主干网的连接只有 1Gb。因此，您不仅与其他客户的网络操作存在争用，而且与他们的磁盘和您的磁盘也存在网络争用。实际上，除非您与许多其他高流量客户共享机箱，否则网络争用通常不是问题。您可以通过使用更大的实例（更大的实例占用更大比例的机箱，因此共享的资源更少）来解决其中的一些问题。
在峰值和这些问题期间，您遇到了什么样的 iop？（sar -d tps 列）
这些期间您的窃取时间是多少？（iostat -x 1 或 sar -u）。
您可以通过软件 RAID 将多个 EBS 卷组合在一起来增加 IOP 容量，这应该有助于缩短 iowait 时间。这听起来很笨拙，但实际上却有效。这不会解决网络争用问题，但考虑到您的流量，我非常怀疑您的链路是否已饱和。不过，另一个客户可能已经饱和，并给您带来了一些麻烦。
不幸的是，有时，解决此类问题的一个简单方法是简单地重新旋转实例。它可能会出现在具有不同共享客户的不同主机上。EC2 客户通常会旋转实例，运行一些基准测试，如果他们对结果不满意，则重新旋转。
另一个建议是将 Web 和数据库层拆分到不同的服务器中。出于多种原因，将 Web/DB 放在一台服务器上通常不是一个好主意，在这种情况下，可能会使诊断瓶颈变得更加困难。
答案2
最有可能的是（正如您指出的那样，您找到了第二个问题的解决方案）这些问题是配置问题或其他原因。EC2/EBS/任何云技术都不是问题的根源。与迄今为止收到的答案相反，这些是您在任何环境中都会遇到的问题。
此外，亚马逊确实提供了 SLA。虽然极少见，但有些资源可能会发生争用。不过，考虑到您当前的使用情况，这种情况不太可能发生。我将继续对各种争用点进行诊断研究，并与亚马逊 Web 服务的技术团队进行交流。此外，请查看他们的论坛，因为那里通常有非常博学的人。您可能知道论坛，但以防万一，请在此处查看： https://forums.aws.amazon.com/index.jspa
此外，仅从架构角度来看，您是否考虑过将此负载分配到多个 EC2 实例并进行负载平衡？这是一个应该可以解决其中一些问题的选项。此外，从您正在讨论的架构来看，如果您将工作拆分为一些功能稍弱的实例并进行分配，总体而言可能会更好。另一个优点是，如果您的网站/服务继续增长，您可以很好地进行水平扩展而不是垂直扩展，后者当然受到限制。
答案3
首先，对于您的网站负载遇到严重问题，我深感抱歉。据我所知，所有这些都应在应用程序可用性和性能的 SLA 政策中概述，您应该有权获得补偿。
正如 user37899 所说，如果这是一个任务关键型应用程序和密集型操作，那么使用共享公共云并不是理想的平台。共享的问题在于，您不仅不确定您的进程在哪里运行，而且您的性能还会受到该网格上其他客户的影响。存储很可能是该特定网格上的共享资源，导致您的性能下降。
Amazon x64 xLarge 部署应该有适当的规范，但是如上所述，磁盘资源虽然由其卷和 raid 配置划分出来，但仍然可以从共享池中访问。
我有兴趣进一步了解您所拥有的内容以及其他一些性能计数器和数据库架构，以便最好地提供适当的响应来解决此问题。虽然在我看来，更好的解决方案是至少将您的数据库层放在裸机上或使用其自己的专用硬件的私有云中。
请随时给我留言，我可以聊天，祝你好运。