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がリリースされた後、間違いなく良くなったからです。しかし、私たちのヘルスチェックはロードバランサーごとに異なり、最も問題が発生しているものが見つかりました。非常に積極的な不健康なしきい値と応答タイムアウトがありました。私たちのトラフィックは予想外に急上昇する傾向があり、積極的なヘルスチェック設定とトラフィックの急上昇の間で、それは完璧な嵐だったと思います。

ELBロードバランサーがヘルスチェックを実行し、設定ミス（通常はNameVirtualホストで）により「ページが見つかりません」（またはその他の単純なエラー）を受信すると、「バックエンドサーバーはキャパシティ」になります。

「ELB-HealthChecker」ユーザーエージェントを使用して、ログファイルフォルダーをgrepしてみてください。例えば

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

通常、これにより4xまたは5xエラーが発生しますが、これは簡単に修正できます。例：フラッディング、MaxClientsなどは、問題に多大なクレジットを与えています。

FYI Amazon：リクエストから返された応答を表示しないのはなぜですか？ステータスコードも役立ちます。

私は自分でこの問題にぶつかりました。正常なインスタンスがない場合、Amazon ELBはこのエラーを返します。サイトの構成が間違っていたため、ELBヘルスチェックが失敗し、ELBが2つのサーバーのローテーションを停止しました。正常なサイトがゼロの場合、ELBは503 Service Unavailableを返しました。バックエンドサーバーはキャパシティです。

[質問をよりよく理解してから編集] ELBの経験がなくても、ApacheがTomcatを前面に出し、接続をフラッディングするときにスローされる可能性のある503エラーのように聞こえます。

その結果、Apacheがバックエンドで処理できるよりも多くの接続要求を配信すると、それ以上接続が受け入れられなくなるまでバックエンドの入力キューがいっぱいになります。それが起こると、Apacheの対応する出力キューがいっぱいになり始めます。キューがいっぱいになると、Apacheは503をスローします。Apacheがバックエンドであり、フロントエンドがキューがいっぱいになるような速度で配信する場合にも同じことが起こります。

（仮想的な）解決策は、バックエンドの入力コネクタとフロントエンドの出力コネクタのサイズを決めることです。これは、予想されるフラッディングレベルと関連するコンピューターの使用可能なRAMの間のバランスをとる行為になります。

そのため、maxclientsの設定を確認し、Apache（mod_status。）で忙しいワーカーを監視してください。Tomcatのバックログ、maxthreadsなどに対応するELBがあれば、可能であれば同じことを行います。要するに、Apacheの入力キューとELBの出力キューに関するすべてを見てください。

直接適用できないことは完全に理解していますが、このリンクにはApacheコネクタのサイズ設定ガイドが含まれています。対応するELBキューの技術を調査してから、数学を実行する必要があります。http： //www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- full-gc /

以下の解説で見られるように、Apacheコネクタを圧倒するのは、トラフィックの急増だけではありません。一部のリクエストの処理が他のリクエストよりも遅い場合、それらの割合が高いと、コネクタキューがいっぱいになる可能性があります。これは私の場合に当てはまりました。

また、これが私に起こったとき、503：sを再び提供されないようにするために、Apacheサービスを再起動する必要があることに困惑しました。コネクタのフラッディングを単に待つだけでは十分ではありませんでした。私はそれを理解していませんでしたが、おそらくApacheがそのキャッシュからサービスを提供していると推測できますか？

ワーカーの数と対応するpre-fork maxclients設定（これはWindowsのマルチスレッドApacheで、正しく覚えていればキューに対する他のディレクティブがいくつかありました）を増やした後、503の問題はなくなりました。実際には計算しませんでしたが、キューリソースのピーク消費量に大きなマージンが見られるまで値を微調整しました。私はそれを手放します。

これが助けになることを願っています。

elb健全性チェッカーの値を上げることができるため、1つの遅い応答がelbからサーバーをプルすることはありません。数人のユーザーがサービスを利用できないようにする方が、サイトが全員のためにダウンするよりも優れています。

編集：ヘルスチェックのタイムアウトを25秒にアップすることにより、キャッシュを事前に温めることなく逃げることができます...... 1〜2分後...サイトは地獄のように反応します

編集：：オンデマンドの束を起動し、監視ツールがあなたの管理がどれだけ速いかを示したら、RI Amazon：Pを前払いするだけです

編集：可能です。単一のバックエンドelb登録済みインスタンスでは不十分です。さらにいくつか起動して、それらをelbに登録すると、問題を絞り込むのに役立ちます

それは数年遅れていますが、うまくいけばこれは誰かを助けます。

ELBの背後のインスタンスに適切なパブリックIPが割り当てられていないときに、このエラーが表示されていました。Elastic IPを手動で作成し、インスタンスに関連付ける必要がありました。その後、ELBがほぼ瞬時にそれを取得しました。