JSP*_*JSP 41 503-error apache-2.2
我们已经在亚马逊 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 后面的网络服务器运行。任何建议将不胜感激。
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 启动后它肯定会变得更好，但我发现我们的运行状况检查对每个负载均衡器都是不同的，并且是最麻烦的那个有一个非常激进的不健康阈值和响应超时。我们的流量往往不可预测地激增，我认为在激进的健康检查设置和流量高峰之间，这是一场完美的风暴。
Cha*_*ass 42
当 ELB 负载均衡器执行其运行状况检查并由于配置错误（通常是 NameVirtual 主机）而收到“找不到页面”（或其他简单错误）时，您将收到“后端服务器容量不足”的消息。
尝试使用“ELB-HealthChecker”用户代理搜索日志文件文件夹。例如
grep ELB-HealthChecker /var/log/httpd/*
这通常会给你一个 4x 或 5x 的错误，很容易修复。例如 Flooding、MaxClients 等给这个问题太多的功劳。
仅供参考亚马逊：为什么不显示请求返回的响应？即使是状态代码也会有所帮助。
小智 18
我自己刚刚遇到了这个问题。如果没有健康的实例，Amazon ELB 将返回此错误。我们的站点配置错误，因此 ELB 运行状况检查失败，导致 ELB 使两台服务器停止轮换。对于零个健康站点，ELB 返回 503 服务不可用：后端服务器已满。
[更好地理解问题后编辑] 没有任何 ELB 经验，我仍然认为这听起来很像 503 错误，当 Apache 前端 Tomcat 并淹没连接时可能会抛出该错误。
结果是，如果 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-全GC/
正如在下面的评论中所观察到的，要压倒 Apache 连接器，流量激增并不是唯一的可能性。如果某些请求的处理速度比其他请求慢，则这些请求的比率较高也会导致连接器队列填满。在我的情况下确实如此。
此外，当这发生在我身上时，我感到困惑的是我必须重新启动 Apache 服务才能不再获得 503:s 服务。仅仅等待连接器泛滥是不够的。我从来没有弄清楚，但是也许可以推测 Apache 从其缓存中提供服务？
在增加工作人员的数量和相应的 pre-fork maxclients 设置（这是 Windows 上的多线程 Apache，如果我没记错的话，它有几个其他队列指令），503 问题消失了。我实际上没有做数学计算，只是调整了值，直到我可以观察到队列资源的峰值消耗有很大的余量。我就让它过去了。
希望这会有所帮助。