web-dev-qa-db-ja.com

Apacheが（危機に瀕している）リクエストに圧倒されているかどうかを検出する方法は？

私はUbuntuでApache2を実行しているEC2サーバーインスタンスを維持および計画しており、現在1時間あたり最大約10000（非常に単純な）リクエストを受信して​​います。 POSTで入力されるデータの一部であり、ダミーのプレーンテキストハイフンが応答されます。

リクエストの量は、時間とともに徐々に増加し、1時間あたり約100万になります。

サーバーがひざまずき、着信要求を処理できなくなったことを（確実に>）検出するにはどうすればよいですか？

現在私が行っているのは、htopのメモリとCPUの負荷をチェックすることです。これらが全容量に達していない場合は、すべて問題ないと思います。

apache-2.4high-load
2
Raffael

あなたはシステムリソースを正しく監視していると思います。負荷平均、IO負荷、メモリ、スワップ、CPUなど...

プロセスが実際に行っていることなど、Apacheの内部ステータスに関する詳細からおそらく恩恵を受けるでしょう。

http://www.tecmint.com/monitor-Apache-web-server-load-and-page-statistics/

Mod_statusがwww.Apache.orgから表示できるものの例

http://www.Apache.org/server-status

これは、時間をかけて情報を収集し、後で全体を確認するのに役立つ場合があります

https://httpd.Apache.org/docs/2.4/programs/log_server_status.html

セットアップによっては、データベースサーバーなどのApacheが使用しているバックエンドサービスのパフォーマンスを個別に監視する必要があります。

2
Ryan Babchishin

エンドユーザーに対するApacheのパフォーマンスの定量化に関しては、応答の提供にかかる時間は有用であり、サーバーの負荷とともに増加します。私は通常、この値のログをawstatsやwebalizerなどのWeb分析ソフトウェアと組み合わせます。

残念ながら、デフォルトのログ形式ではこれが表示されないため、Apacheでカスタムログ形式を使用しています。これは例です。

# Define logfile format used for response time analysis
LogFormat "\"%{%Y-%m-%d %H:%M:%S}t\" %V %m \"%U\" \"%q\" %{Content-Type}o %s %B %O %D" responsetime
CustomLog "/var/log/Apache2/responsetime.log" responsetime

カスタムログ形式ディレクティブ％Dは要求時間を与えます。

％Dリクエストの処理にかかる時間（マイクロ秒単位）。

Apacheドキュメント：
http://httpd.Apache.org/docs/current/mod/mod_log_config.html

ここからの例;
http://www.moeding.net/archives/33-Logging-Apache-response-times.html

2
Tom H

免責事項：私はwww.mosoplot.comで働いています。これは、ここで必要な容量計画のほとんどを自動化します。これを行う方法を示すために、MOSOplotのいくつかのチャートを使用しました。

これが私がWebサーバーの容量計画を行う方法です。

最初の考慮事項は、Htop/topの使用はこの種の分析には適していないということです。これらは、パフォーマンス分析には最適ですが、キャパシティプランニングには悪臭を放つ、最も極端な短期的なビューのみを示しています。これを正確に判断するには、実際にはもっと長い時間枠を調べる必要があります。それは、国の宗教的な構成を決定するために数人をサンプリングするようなものです。あなたが見ていた短い期間が、残りの時間サーバーで何が起こっているかを代表していることをどうやって知っていますか？あなたが眠っているときはどうですか？ピーク時かどうかもわかりますか？

Htopもデフォルトで2秒間隔のみを使用します。したがって、スパイクは出入りし、重要な場合と重要でない場合があります。実際、キャパシティプランニングの最小間隔は5分ですが、私は1時間を好みます。これにより、スパイクが滑らかになり、根本的な傾向が示されます。それはあなたが計画する必要があるものです。ただし、短期的な傾向があると考える理由がある場合（たとえば、すべての転送が各時間の開始時に10分間発生する場合）、必ずそれを確認してください。

ステップ1：データを収集して保存します。

MOSOplotはcollectdエージェントを使用します。このエージェントは、Apacheメトリックとシステムメトリックを収集できます。

Apacheの統計（応答時間とボリューム）を取得するには、collectd tailプラグインを使用できます。このプラグインは、Apacheログファイルを読み取り、必要なデータを抽出します。専用のApacheプラグインがありますが、応答時間は取得されません。

このようなものは、％Dを含めるためにTomHによって概説された構成の変更とともに開始する必要があります。

LoadPlugin tail
<Plugin "tail">
 <File "/var/log/Apache2/access.log"> <-- PUT IN CORRECT FILENAME
  Instance "Apache"
  <Match>
   Regex "GET.*?\\s([0-9\\.]+)\\s[0-9\\.]+$"
   ExcludeRegex "\\s/(favicon|wp-)"
   DSType "GaugeAverage"
   Type "response_time"
   Instance "last_byte"
  </Match>
 </File>
</Plugin>

ステップ2：主要なリソース指標を確認する

  • 反応時間
  • トランザクション数
  • CPU使用率
  • メモリ使用率

注目すべき最も重要な指標は応答時間です。アプリケーションがバッチシステムでない限り、これは無視してかまいません。

CPUとメモリの使用率を応答時間と相関させてみてください。これにより、システムがいつ故障するかがわかります。応答時間は通常の5倍に増加する可能性がありますが、その後急速に悪化する可能性があります。ただし、一部のアプリケーションではそれを処理できない場合もあるため、状況によって異なります。

これは、CPUとWebサーバーのヒット数/分を比較する例を示すグラフへのリンクです。この場合、音量は小さく、15ヒット/分に快適に到達できたようです。 cpu vヒット/分

ステップ3：いつアップグレードするか

応答時間を収集できなかった場合は、固定のしきい値を使用する必要があります。 CPUやメモリがフルキャパシティーに近づくまで絶対に待たないでください。まず、約60％（時間平均）で低下し始めるでしょう。次に、Amazonは一部のシステムで60％のマークでバーストモードを使用しています。これは、これが適切なしきい値であると考えていることを示す良い指標です。バーストレベルを頻繁に超える場合は、アップグレードを検討する必要があります。

メモリは約90％までは問題ないはずですが、ApacheでOOMの問題が発生することがあることを考えると（nginxの方が優れています）、ピーク使用率が70％の方が幸せです。

Apacheは、メモリ使用量によって非常に不安定になる傾向があります。私たちが監視している1つのWebサーバーでは、RAMが1GBしかない小さなインスタンスであり、ApacheでOOMエラーが発生していたため、最終的にnginxに変更しました。これは、nginxと比較してApacheでRAMの使用量が急増していたことを示すグラフです。 Apache v nginxのメモリ変数

ここで考えるべきもう1つのことは、approvalをどれだけ早くアップグレードできるかということです。 AWSでの実際のアップグレードは迅速かもしれませんが、アプリがスケーラブルであると仮定すると、私が使用しているほとんどのクライアントでアップグレードの承認を得るのは、まあ、氷河です！それがあなたが必要とするものであるならば、あなた自身に数週間/月の余裕を与えてください。

1
Nathan Webb