大约两年来，我们在 Amazon AWS 基础设施上运行了几个网站，大约两天前，网络服务器开始每天宕机一两次，我发现的唯一错误是：
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
CloudWatch 没有触发任何警报（CPU/磁盘 IO/DB Conn）。我尝试通过弹性 IP 访问该站点以跳过 ELB，结果如下：
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.
我在 apache 日志中没有看到任何异常，并确认它们正在正确轮换。当机器“关闭”时，我通过 SSH 访问机器没有任何问题，查看进程列表时，我看到 151 个 apache2 进程在我看来很正常。重新启动 apache 可以暂时解决问题。这台机器只是作为 ELB 后面的 Web 服务器运行。任何建议都将不胜感激。
CPU 利用率平均值：7.45%，最小值：0.00%，最大值：25.82%
内存利用率平均值：11.04%，最小值：8.76%，最大值：13.84%
交换利用率平均值：N/A，最小值：N/A，最大值：N/A
/dev/xvda1 安装在 / 上的磁盘空间利用率平均值：62.18%，最小值：53.39%，最大值：65.49%
让我澄清一下，我认为问题出在单个 EC2 实例上，而不是 ELB 上，我只是不想排除这种可能性，尽管我无法访问弹性 IP。我怀疑 ELB 只是返回了访问实际 EC2 实例的结果。
更新：2014-08-26 我应该早点更新这个，但“修复”是拍摄“坏”实例的快照并启动生成的 AMI。从那时起它就再也没有出现过故障。当我仍然遇到问题时，我确实查看了健康检查，curl http://localhost/page.html即使我从负载平衡器中得到容量问题，我也可以进入健康检查页面 ()。我不相信这是一个健康检查问题，但由于没有人（包括亚马逊）可以提供更好的答案，我将其标记为答案。谢谢。
更新：2015-05-06 我想回到这里说我现在坚信问题的一部分是健康检查设置。我不想排除 AMI 的问题，因为在推出替代 AMI 后情况肯定有所好转，但我发现我们的健康检查对每个负载均衡器都不同，而问题最严重的负载均衡器有一个非常激进的不健康阈值和响应超时。我们的流量往往会不可预测地激增，我认为激进的健康检查设置和流量激增之间是一场完美风暴。在诊断问题时，我专注于这样一个事实：我目前可以到达健康检查端点，但健康检查可能由于延迟而失败，然后我们有一个很高的健康阈值（对于那个特定的 ELB），所以需要一段时间才能看到实例再次健康。
答案1
当 ELB 负载均衡器执行其运行状况检查并由于配置错误（通常是 NameVirtual 主机）而收到“页面未找到”（或其他简单错误）时，您将收到“后端服务器已满负荷”的信息。
尝试使用“ELB-HealthChecker”用户代理来 grep 日志文件文件夹。例如
grep ELB-HealthChecker /var/log/httpd/*
这通常会导致 4 倍或 5 倍错误，但这些错误很容易修复。例如，Flooding、MaxClients 等给该问题带来了太多困扰。
仅供参考，亚马逊：为什么不显示请求返回的响应？即使是状态代码也会有帮助。
答案2
我自己也遇到了这个问题。如果没有健康实例，Amazon ELB 将返回此错误。我们的站点配置错误，因此 ELB 健康检查失败，导致 ELB 使两台服务器无法轮换。由于没有健康站点，ELB 返回 503 服务不可用：后端服务器已满负荷。
答案3
[更好地理解问题后进行编辑] 由于没有任何 ELB 经验，我仍然认为这听起来很像 Apache 前端 Tomcat 并淹没连接时可能抛出的 503 错误。
结果是，如果 Apache 发送的连接请求多于后端可以处理的数量，后端输入队列就会填满，直到无法再接受连接为止。当发生这种情况时，Apache 的相应输出队列也会开始填满。当队列已满时，Apache 会抛出 503。因此，当 Apache 是后端时，如果前端的发送速率足以填满队列，也会发生同样的情况。
（假设的）解决方案是确定后端的输入连接器和前端的输出连接器的大小。这变成了预期的洪水级别和相关计算机的可用 RAM 之间的平衡行为。
因此，当这种情况发生时，请检查您的 maxclients 设置并监控 Apache 中的繁忙工作进程 (mod_status)。如果可能，请对与 Tomcats 连接器积压、maxthreads 等相对应的 ELB 执行相同操作。简而言之，查看与 Apache 的输入队列和 ELB 的输出队列相关的所有内容。
虽然我完全理解它并不直接适用，但此链接包含 Apache 连接器的大小指南。您需要研究相应的 ELB 队列技术，然后进行计算： http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during-full-gc/
正如下面的评论中所述，流量激增并不是压垮 Apache 连接器的唯一可能。如果某些请求的处理速度比其他请求慢，那么这些请求的比例较高也会导致连接器队列填满。就我的情况而言，确实如此。
此外，当这种情况发生在我身上时，我很困惑，我必须重新启动 Apache 服务才能避免再次收到 503:s 服务。仅仅等待连接器泛洪是不够的。我从来没有弄清楚，但有人可以推测 Apache 可能从其缓存中提供服务？
在增加工作进程数和相应的预分叉最大客户端设置后（如果我没记错的话，这是 Windows 上的多线程 Apache，它还有其他几个队列指令），503 问题就消失了。我实际上没有做计算，只是调整了值，直到我能够观察到队列资源峰值消耗的较大幅度。我就放手了。
希望这能有所帮助。
答案4
虽然晚了几年，但希望这可以为某些人提供一些帮助。
当 ELB 后面的实例没有分配正确的公共 IP 时，我会看到此错误。我需要手动创建一个弹性 IP 并将其与实例关联，之后 ELB 几乎立即获取了它。