5
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之后，它肯定会变得更好，但是我发现我们的运行状况检查对于每个负载均衡器都是不同的，并且最麻烦的是有一个非常激进的不健康阈值和响应超时。我们的流量趋向于无法预料地激增，我认为在积极的健康检查设置和流量激增之间，这是一场完美的风暴。