AWS ELB Apache2 503服务不可用:后端服务器已启用

我们已经在亚马逊AWS基础设施上运行了两年多的网站,大约两天前,networking服务器每天开始下降一到两次,唯一的错误是我能find的:

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后面的networking服务器。 任何build议将不胜感激。

CPU利用率平均:7.45%,最小:0.00%,最大:25.82%

内存利用率平均:11.04%,最低:8.76%,最高:13.84%

交换使用平均值:N / A,最小值:N / A,最大值:N / A

/ dev / xvda1的磁盘空间利用率安装在/ Average: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更换后AMI的确有所改善,但是我发现我们的健康检查对于每个负载平衡器都是不同的,而且那个最麻烦的有一个非常积极的不健康的门槛和响应超时。 我们的stream量往往难以预料,我认为在积极的健康检查环境和交通高峰期间,这是一场完美的风暴。 在诊断这个问题时,我把注意力集中在我能够到达健康检查终点的事实上,但是由于延迟,健康检查可能失败了,于是我们有一个很高的健康阈值(对于那个特定的ELB)拿一会儿看实例再次健康。

当ELB负载均衡器执行健康检查并由于错误configuration(通常使用NameVirtual主机)而收到“未find页面”(或其他简单错误)时,您将得到“后端服务器处于满负荷状态”。

尝试使用“ELB-HealthChecker”用户代理刷新日志文件文件夹。 例如

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

这通常会给你一个容易修复的4x或5x的错误。 例如洪水,MaxClients等给问题太多信用。

仅供参考亚马逊:为什么不显示请求返回的响应? 即使是状态码也会有帮助。

我自己也遇到过这个问题 如果没有健康的实例,Amazon ELB将返回这个错误。 我们的网站configuration错误,所以ELB健康检查失败,这导致ELB使两台服务器不能轮换。 零健康网站,ELB返回503服务不可用:后端服务器处于可用状态。

[编辑后更好地理解这个问题]没有任何经验的ELB,我仍然认为这听起来像503错误,可能是当Apache面对一个雄猫和泛滥的连接可能会引发。

结果是,如果Apache提供的连接请求多于后端可以处理的连接请求,则后端input队列将被填满,直到不能接受更多的连接。 发生这种情况时,Apache的相应输出队列开始填满。 当队列满了的时候,Apache会抛出一个503.这样,当Apache是​​后端时,会发生同样的情况,而前端以这样的速度递送,使得队列填满。

(假设的)解决scheme是调整前端的后端和输出连接器的input连接器的大小。 这变成了所预期的洪水水平与所涉及的计算机的可用RAM之间的平衡操作。

所以发生这种情况时,请检查您的maxclients设置并在Apache(mod_status。)中监视您的繁忙工作人员。 如果可能的话,尽可能使用与Tomcats连接器积压,maxthreads等相对应的ELB。简而言之,请查看有关Apacheinput队列和ELB输出队列的所有内容。

虽然我完全理解它不是直接适用的,但是这个链接包含了Apache连接器的大小调整指南。 你需要研究相应的ELB队列技术,然后进行下面的计算: http : //www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during-全GC /

正如在下面的评论中所观察到的,为了压倒Apache连接器,stream量飙升并不是唯一的可能性。 如果某些请求比其他请求更慢,那么这些请求的比例更高也会导致连接器队列填满。 我的情况是这样的。

另外,当这发生在我身上时,我很困惑,为了不再服务于503:s,我必须重新启动Apache服务。 简单地等待连接器泛滥是不够的。 我从来没有得出这个结论,但是我们可以从Apache的caching中推测Apache的服务吗?

在增加了工作人员数量和相应的pre-fork maxclients设置之后(如果我没有记错的话,这是Windows上的multithreadingApache,对于队列有一些其他的指令),503问题就消失了。 实际上我没有做math,只是调整了数值,直到我能够观察到队列资源的高峰消耗。 我放过这个

希望这是一些帮助。

你可以boostelb健康检查器的价值,所以作为一个慢速的回应将不会从elb拉一个服务器。 最好有几个用户得到服务不可用,比网站被closures的每个人。

编辑:我们能够通过提高健康检查超时25秒,预热caching…… 1-2分钟后……网站是响应作为地狱

编辑::只是推出一堆的需求,当你的监测工具显示pipe理只是有多快,那么只是预付款RI亚马逊:P

编辑:有可能,一个单一的后端elb注册实例是不够的。 只需启动几个,并注册他们与elb,这将帮助你缩小你的问题

这是晚了几年,但希望这可以帮助别人。

当ELB背后的实例没有分配适当的公共IP时,我看到这个错误。 我需要手动创build一个Elastic IP,并将其与实例关联起来,然后ELB几乎立即将其拾取。