我有一个 m1.medium Amazon EC2 实例，运行 Apache 并托管一个 Wordpress 博客。反过来，Wordpress 与另一个 EC2 实例上的 MySQL 数据库一起工作。Wordpress 网站已设置 W3 Total Cache 并运行良好，网站上的大部分静态内容由 CDN 提供。该网站的流量通常很少，然后偶尔会出现一些巨大的流量高峰……当这些高峰出现时（超过约 150 人访问该网站），该网站就会瘫痪。我还可以借助一些负载测试工具每次都让这种情况发生。
这是主服务器空闲时的“顶部”：
top - 23:21:23 up 103 days, 19:40, 3 users, load average: 0.91, 0.60, 0.62
Tasks: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.9%sy, 0.0%ni, 99.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3844856k total, 1756268k used, 2088588k free, 150132k buffers
Swap: 0k total, 0k used, 0k free, 833740k cached
但是，如果我进行一些负载测试来模拟数百个用户访问静态图形文件（这显然不会触发 Wordpress、PHP 或数据库），一切都很好：服务器负载保持在较低水平，图形文件快速提供，等等。
我的 Apache 设置（服务器内存 3.1G / 每个 httpd 实例约 8100k = 约 400 MaxClients）：
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 400
MaxClients 400
MaxRequestsPerChild 0
因此，基于所有这些，问题似乎与使用 PHP 或 MySQL 有关。
在 MySQL 服务器上，无论我做什么，负载基本保持在 0，慢速查询日志保持为空……所以我认为那里一切正常。以下是我对 SQL 服务器的“top”：
top - 23:20:21 up 103 days, 19:12, 5 users, load average: 0.08, 0.03, 0.05
Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3844856k total, 1076912k used, 2767944k free, 158412k buffers
Swap: 0k total, 0k used, 0k free, 638092k cached
这一切都让我想到，以下不太可能发生的情况之一正在发生：
- 这台机器的原始马力根本无法满足 150 多个并发用户的需求，我应该升级到 L 或 XL EC2 实例。也许吧，但是……真的吗？对于一个相对强大的服务器来说，150 个用户太多了m1.中等服务器？
- Apache 根本就不是为处理这种流量而设计的。值得怀疑。
- Web 和数据库服务器之间的通信存在问题。但我对此表示怀疑，因为这是两个 Amazon EC2 实例之间的通信。
我觉得我已经检查了所有能检查的，但还是没找到。我还应该检查什么？我还能尝试什么？
答案1
在这种情况下，m1.medium 的“马力”相当于一个 CPU，显示 top 时负载为 0.91。负载为 0.91 意味着“现在，一个 CPU 的 91% 的工作正在被进程请求。”简而言之，当您处于空闲状态时，似乎有什么东西占用了您的 CPU。
假设这就是问题所在，我会削减消耗 CPU 的服务。如果这在您的主服务器上不是一个选项，我会为您现有的机器创建一个 ami，然后再旋转两个主机，实例类型为 t1.micro，并确保只有最低限度的服务在其上运行（在本例中为 apache）。然后循环 dns 您的网站地址。这将有效地将您的突发 CPU 容量增加三倍，同时提供 2 倍的 CPU 基线。
答案2
我们通过 EC2 上的较小实例为大量用户提供服务（并且使用 apache 基准测试最多 1000 个并发会话）。
好消息是您可以重现它。
您可以检查很多事情：
在两台服务器上都放置一个类似 new relic 的工具（首先使用免费版本来记录 CPU/内存历史记录）。这对于趋势分析来说还是不错的。
从 2 个服务器之间的通信开始。进行一些文件传输并检查速度。
我们遇到了 wp-cron.php 不时关闭 wordpress 服务器的问题。尝试禁用该问题并将其每隔几分钟移至 cron 调用。
报告你的发现，我可以提出更多想法。