AWS ELB Apache2 503服务不可用：后端服务器已满负荷

我们已经在亚马逊的AWS基础设施上运行了两个网站，并且大约两天前，网络服务器开始每天停机一两次，我发现的唯一错误是：

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

CloudWatch不会触发任何警报（CPU /磁盘IO / DB连接）。我尝试通过弹性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％

交换平均利用率：不适用，最小值：不适用，最大值：不适用

安装在/ 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负载平衡器执行其运行状况检查并由于配置错误（通常是NameVirtual主机）而收到“找不到页面”（或其他简单错误）时，您将获得“后端服务器已满”。

尝试使用“ ELB-HealthChecker”用户代理重复记录日志文件文件夹。例如

grep ELB-HealthChecker  /var/log/httpd/*

这通常会给您4x或5x的错误，很容易解决。例如Flooding，MaxClients等给问题方式带来了太多荣誉。

仅供参考，为什么不显示从请求返回的响应？甚至状态码也会有所帮助。

我只是自己碰到这个问题。如果没有正常的实例，Amazon ELB将返回此错误。我们的站点配置错误，因此ELB运行状况检查失败，这导致ELB取消了两台服务器的旋转。在零个健康站点的情况下，ELB返回503服务不可用：后端服务器已满。

[更好地理解问题后再进行编辑]没有ELB的经验，我仍然认为这听起来像503错误，当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-全gc /

正如下面的评论所指出的那样，使Apache连接器不堪重负不是唯一的可能。如果某些请求的处理速度比其他请求慢，则这些请求的比率也可能导致连接器队列填满。就我而言，这是真的。

另外，当这发生在我身上时，我为无法再次获得503：s而不得不重启Apache服务感到困惑。仅等待连接器泛洪是不够的。我从来没有想过，但是可以从它的缓存中推测Apache服务吗？

增加工作程序的数量和相应的前叉maxclients设置（如果我没记错的话，这是Windows上的多线程Apache，它还有几个其他队列指令），503问题消失了。我实际上并没有进行数学运算，只是微调了数值，直到观察到队列资源的峰值消耗有较大幅度。我随它去吧。

希望这会有所帮助。

您可以提高elb运行状况检查器的值，这样一个缓慢的响应就不会从elb中拉出服务器。最好是让一些用户无法获得服务，而不是每个人都无法访问该网站。

编辑：我们可以通过将运行状况检查超时时间提高到25秒，而无需提前预热缓存……1-2分钟后...站点响应迅速

编辑：：只需启动一堆随需应变的工具，当您的监视工具显示管理速度时，您只需预付RI亚马逊：P

编辑：有可能，单个后端elb注册实例是不够的。再启动一些，然后在elb上注册，这将帮助您缩小问题范围

已经晚了几年，但希望这可以帮助某人。

当ELB后面的实例未分配适当的公共IP时，我看到此错误。我需要手动创建一个弹性IP并将其与实例关联，此后，ELB几乎立即将其拾取。