AWS ELB Apache2 503サービスを利用できません：バックエンドサーバーの容量が不足しています
AmazonsのAWSインフラストラクチャからいくつかのウェブサイトを約2年稼働しており、約2日前にウェブサーバーが1日1〜2回ダウンし始めましたが、エラーは1つしかありません。 HTTP/1.1 503 Service Unavailable: Back-end server is at capacity CloudWatchによってトリガーされるアラーム（CPU /ディスクIO / DB接続）はありません。ELBをスキップするためにElastic IP経由でサイトにアクセスしてみたところ、次のようになりました： 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ているときにヘルスチェックを確認し、ロードバランサーから容量の問題が発生している場合でもヘルスチェックページ（）にアクセスできるようにしました。私はそれがヘルスチェックの問題だとは確信していませんが、Amazonを含む誰もより良い答えを提供できないので、私はそれを答えとしてマークしています。ありがとうございました。 更新：2015-05-06ここに戻って、今私がしっかりと信じている問題の一部はヘルスチェックの設定だと言ったと思いました。AMIの問題であることを除外したくありません。交換用AMIがリリースされた後、間違いなく良くなったからです。しかし、私たちのヘルスチェックはロードバランサーごとに異なり、最も問題が発生しているものが見つかりました。非常に積極的な不健康なしきい値と応答タイムアウトがありました。私たちのトラフィックは予想外に急上昇する傾向があり、積極的なヘルスチェック設定とトラフィックの急上昇の間で、それは完璧な嵐だったと思います。