EC2：没有明显资源争用的常规性能问题

Question

我们在 Ubuntu 9.10 x64 xlarge Amazon EC2 实例上运行 LAMP+memcached。这个服务器每秒处理几百个请求，其中大约 60% 是静态的，其余的都以某种方式与 mysql 和/或 memcached 交互。此服务器一直存在两个可能相关且已证明难以诊断的性能问题。除非另有说明，否则以下所有统计数据都是使用 CloudWatch、munin 或 vmstat/iostat/top 收集的。

1. 第一个问题是每隔几分钟重复出现高 iowait 的定期峰值，在此期间，大多数 apache 进程同时 iowait 大约 10-30 秒，然后所有未挂起。在此期间没有增加磁盘或网络负载，磁盘队列保持低位，没有进行交换等。

2. 更严重的是，在高峰时段，服务器有时会突然体验到性能的急剧下降，将服务请求降低到之前的大约 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 访问日志记录以最小化磁盘访问。

Answer 1

首先，最重要的是，很抱歉您的网站负载遇到了严重问题，据我所知，所有这些都应在有关应用程序可用性和性能的 SLA 政策中概述，您应该有权获得积分。

如果是任务关键型应用程序和密集型操作，则使用共享公共云（如 user37899 所评论的那样）并不是理想的平台。共享的故事不仅是您不确定流程在哪里运行，而且您的性能还受到该网格上其他客户的影响。存储很可能是该特定网格上的共享资源，这会导致性能下降。

Amazon x64 xLarge 部署应该正确指定，但是如上所述，尽管磁盘资源是由其卷和 raid 配置划分的，但仍然可以从共享池进行访问。

我有兴趣更多地了解您所拥有的内容以及其他一些性能计数器和数据库体系结构，以帮助最好地提供适当的响应来解决此问题。尽管在我看来，更好的解决方案是至少将数据库层放在裸机上或使用自己的专用硬件放在私有云中。

请随时给我留言，我可以聊天，祝你好运。