多くのVirtualHostを実行しているApacheWebサーバーがあります。
最近、問題が発生して応答しなくなってきました。どのVirtualHostが問題の大部分を引き起こしているのかをどのように判断できるのでしょうか。過去に、個々のサイトのコードのバグによってサーバー全体がダウンすることがありました。私の目標は、これらのインスタンスを迅速に診断できるようにすることです。
muninでサーバーを監視していますが、問題の期間中、Apacheプロセスの数、メモリ使用量、および負荷が非常に高くなる傾向があることに気付きました。問題は、これらの統計はWebサーバー全体に関するものであり、個々のVirtualHostに関するものではないということです。
ウェブログを解析するスクリプトを作成しましたVirtualHostごとのトラフィックですが、それだけでは不十分なようです。私はおそらくApacheプロセスの数各VirtualHostが責任を負っている、または各プロセスを開いたままにしておく時間-またはおそらくメモリの量を決定する必要がありますそれぞれが責任を負う使用法。
この情報はどこにありますか?このデータを追跡するスクリプトを作成してもかまいませんが、そもそもどこからデータを抽出するのか正確にはわかりません。
Mod_statusを常に利用できるとは限らないことを理解していますが、mod_statusとapachetopがこれらの問題を診断するための最良の方法です。しかし、猫の皮を剥ぐ方法はたくさんあります。
このトリックは多くの状況で役立ち、Apache固有のものだけではありません。ただし、それは多くの要因に依存します。その制限を知るには、それが何をしているのかを知る必要があります。
for pid in `pgrep -u www-data`; do find /proc/${pid}/cwd -printf "%l\n" ; done
それを分解しましょう:
そのトリックには2つの大きな注意点があります。
1)Apacheプロセスと同じコンテキストで実行されている何かがVirtualHostディレクトリの外でchdir()を実行する場合、それを見つけるのは難しいでしょう。
例えばa PHP mod_phpで実行されるスクリプト(Apacheフォークは別のプロセスであるためCGIは異なりますが、CGIは問題ではないか、簡単に追跡できると思います) 。
2)非常に高速にページを提供するApacheインスタンス(小さな静的HTMLページなど)がある場合。これは通常問題ではありませんが、可能かもしれません。 「そのようなファイルまたはディレクトリはありません」というエラーが多数発生する場合、これは基本的にその兆候です。私はいくつかを期待しますが、それらがこの特定のケースに適合しない限り、大多数ではありません。基本的にこれは、psでスキャンしたApacheプロセスが、/ procをチェックした時点ですでに終了しているためです。明らかに、これは彼らが非常に迅速にページを提供していることを意味します。
メモリにバインドされたApacheプロセスに関しては、 ps_mem.py を使用してWebサーバーのメモリ使用量を計算します。大規模なApache(常駐メモリサイズの観点から)プロセスがあり、それらがすぐに終了する場合、それは100メートルのスプリントを実行し続けるように大きな太った男に頼むのとほぼ同じです。ウェブサーバーが共有されていない場合、これらの「そのようなファイルやディレクトリはありません」エラーは通常、一部のコンテンツをより小さな軽量のウェブサーバー(nginx/lighttpdなど)に移動したり、コンテンツの大量のキャッシュを開始したりする(varnish/squidなど)のに適しています。
Apachetop、またはmod_status
(ExtendedStatus On
を使用)が必要だと思います。 mod_status
によってライトアップされなかったApacheのパフォーマンスの問題はまだ発生しておらず、apachetopはきちんとしたツールのように見えます(ログレイアウトにいくつかの厄介な制限があります)。