web-dev-qa-db-ja.com

Apacheサーバーはますます多くのプロセスを生成し、RAM）を最大化して死にかけています

Apacheサーバー（MySQLサーバーはこのボックスにありません）がちょうど死に始めたとき、半年間かなりうまく機能していたLAMPセットアップがあります。時間の経過とともに、ますます多くのプロセスが生成され始めたようです。最終的にはすべてのメモリを消費し、サーバーは停止します。プリフォークを使用しています。

それまでの間、RAMを追加し、MaxClientsとServerLimitパラメーターを512に増やします。しかし、クラッシュが長引くだけです。それでも数はゆっくりと増えます。たぶん1日でそれはその限界に達するでしょう。

何が起こっている？ 1秒あたりのリクエスト数は約15〜20です。メモリには1GBがあり、半分は使用されていません。スワップは発生していません。

Apacheがますます多くのプロセスを作成するのはなぜですか？どこかに漏れがあるようなものです！

データベースボックスは問題なく、リクエストの遅延を引き起こしていません。いくつかのクエリをテストしましたが、すべてが迅速です。

apache-2.2performancelampmpm-prefork
1
erotsppa

[この古い質問に出くわした他の人の利益のために...]

クイックアンサー：

Apache2.confまたはhttpd.confファイルのKeepAlive設定を確認してください。 KeepAliveTimeoutを2〜5秒の間に設定します。

詳細：

デフォルトでは、ApacheのKeepAliveはonであり、KeepAliveTimeoutは15秒に設定されていることがわかりました。つまり、1人のユーザーのページヒットにより、サーバーは同じユーザーが別のページ/リソースを要求するのを15秒間待機してから、他のユーザーの要求を放棄して処理します。

この設定は、ユーザーが最初のindex.htmlファイルを要求し、1〜2秒後にリンクされたCSS、javascript、および画像ファイルを要求する場合に非常に役立ちます。ただし、最近のコンピューターとネットワーク/インターネット接続は、ブラウザーが通常2秒未満でリンクされたリソースを要求していることを意味します。 Apacheはそれらの後続のページを提供し、ユーザーが何か他のものを必要とする場合に備えてさらに15秒間待機します。これは、トラフィックの多い環境では非常に非効率的です。

1秒あたり15の一意の接続を受信し、各接続が15秒間存続する場合、状況が非常に非常に迅速にまとめられることがわかると思います。 225のApacheプロセスがスピンアップし、それらの90％以上が完全にアイドル状態になり、開いている接続で別のページ要求を待機します。

KeepAliveTimeoutを2〜5秒の範囲に設定するための提案をいくつか見てきました。私自身、いくつかのサーバーを2に設定し、他のサーバーを5に設定しています。トラフィックが急増したときに、同じシステムの速度低下が発生しなくなりました。

7
Philbert

あなたのhttpd.confファイルの場合、次のようなセクションがコメントアウトされている可能性があります。

<IfModule mod_status.c>
        <Location "/server-status">
                SetHandler server-status
                Order deny,allow
                Deny from all
                Allow from 127.0.0.1
        </Location>
        ExtendedStatus On
</IfModule>

負荷が高くなりすぎるという問題が発生したサーバーの1つを見ると、同様の問題が見られます...「SS」の行は決して高くなるはずです：

Srv   PID    Acc       M  CPU   SS       ...  Request

0-0   22830  1/9/3640  K  2.36  7        ...  GET /[].css HTTP/1.1
1-0   79114  0/0/858   W  0.00  121462   ...  POST /cgi/[] HTTP/1.1
2-0   22856  0/1/3211  W  0.00  20       ...  POST /cgi/[] HTTP/1.1
3-0   22890  0/0/2697  W  0.00  0        ...  GET /server-status HTTP/1.0
4-0   79105  0/5/525   W  0.34  121463   ...  POST /cgi/[] HTTP/1.1
5-0   22892  1/1/764   K  0.00  6        ...  GET /[].js HTTP/1.1
6-0   22893  1/1/449   K  0.00  5        ...  GET /[].js HTTP/1.1
7-0   22894  1/1/57    K  0.00  5        ...  GET /[].js HTTP/1.1
8-0   22895  1/1/426   K  0.00  4        ...  GET /[].js HTTP/1.1
9-0   -      0/0/40    .  0.00  2        ...  OPTIONS * HTTP/1.0
10-0  22897  0/0/16    _  0.00  4        ...  OPTIONS * HTTP/1.0
11-0  22898  0/0/8     _  0.00  4        ...  OPTIONS * HTTP/1.0

（そのテーブルを表示するには、下にスクロールする必要がある場合があります。上のテーブルはサーバー全体の統計であり、次に各子が現在実行していることを視覚化したものになります）

pdate：もちろん、これは何かがうまくいかないことを前提としています。 （1秒あたりわずか10〜15リクエストのコメントに基づく）。他にも、ファイルをミラーリングしているサーバーがいくつかあります。ファイルが非常に大きいため、帯域幅がそれほど広くない500ストリームを開くことが知られている人が数人いるため、1024接続すべてを消費します。しかし、それは完全に正常であり、クラッシュを引き起こしません。

暴走したCGIで問題が発生した場合は、suExecまたはCGIwrapを使用して実行時間を制限することを検討してください。ただし、それらを使用するとオーバーヘッドが発生します。

2
Joe H.

応答を提供するのに十分なインターネット帯域幅がありますか？着信要求は比例して非常に小さいため、任意のレッグ（LAN、WANなど）を最大にすると、サーバーはネットワークに書き込もうとして山積みになります。

システムのnetstat（1）コマンドを使用して送信キューを確認します。例：「netstat-nat」と送信Q列を見てください。送信データキューがたくさんある場合は、ネットワークのどこかに（物理ネットワークカード以外の）ボトルネックがあることを示しています。

0
Craig Constantine