私はUbuntu 10.04ボックスでmod_wsgi(埋め込みモード)を使用して数十のPython Djangoサイトを実行しています。高速モード(適切に構成されていれば)パフォーマンスは大きく変動します。速いときもあれば、数秒遅れることもあります。スモーキング グラフはあちこちに現れます。
最近、静的コンテンツ用の nginx プロキシも追加しました。これにより、パフォーマンスの大幅な変動が改善されることを期待したからです。しかし、Apache が処理しなければならないリクエストの数が大幅に減ったにもかかわらず、主な問題の解決には役立ちませんでした。
htop を実行中に Web サイトをクリックすると、リクエストがほぼ瞬時に行われる場合もあれば、Apache が数秒間 CPU を 100% 消費する場合もあります。この変動がどこから来るのか、まったく理解できません。
Apache の mpm_worker を次のように設定しました。
StartServers 1
MinSpareThreads 50
MaxSpareThreads 50
ThreadLimit 64
ThreadsPerChild 50
MaxClients 50
ServerLimit 1
MaxRequestsPerChild 0
MaxMemFree 2048
1 台のサーバーに 50 個のスレッド、最大 50 個のクライアント。Munin とapache2ctl -t
両方では、ワーカーが常に存在し、常に破棄されたり作成されたりすることはありません。しかし、そのように動作します。
これサブインタープリタが作成されると、メモリ内に残るはずだと表示されますが、サイトは常にリロードする必要があるようです。
私も nginx+gunicorn ボックスを持っていますが、これはかなりうまく機能します。Apache がなぜこんなにランダムなのか、本当に知りたいです。
これは仮想ホストの設定です:
<VirtualHost *:81>
ServerAdmin [email protected]
ServerName example.com
DocumentRoot /srv/http/site/bla
Alias /static/ /srv/http/site/static
Alias /media/ /srv/http/site/media
WSGIScriptAlias / /srv/http/site/passenger_wsgi.py
<Directory />
AllowOverride None
</Directory>
<Directory /srv/http/site>
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
- ウブントゥ 10.04
- アパッチ2.2.14
- mod_wsgi 2.8
- nginx 0.7.65
編集: サイトの settings.py ファイルに、ロードされるたびに tmp ファイルに日付を書き込むコードをいくつか追加しました。これで、サイトが常にランダムに再ロードされるわけではないことが分かりました。つまり、Apache はそれをメモリに保持しているに違いありません。それでは、答えに近づくことはできませんが、それは良いことです...
編集: これに関連する可能性のあるエラーを見つけました:
File "/usr/lib/python2.6/subprocess.py", line 633, in __init__
errread, errwrite)
File "/usr/lib/python2.6/subprocess.py", line 1049, in _execute_child
self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory
サーバーには 2000 MB のうち 600 MB の空き容量があり、十分なはずです。Apache または WSGI のどこかに制限が設定されているのでしょうか?
答え1
New Relic を使用して、Web アプリケーションに問題があるかどうかを特定しようとしましたか? 無料レベルと最初の完全トライアルもご利用いただけます。New Relic で提供できる内容の概要:
使用されているバックエンド サービスの Web アプリケーションに関する特定の問題が目立たない場合は、WSGI サーバー容量分析レポートに何かが表示されることがあります。これにより、容量が不足しているかどうかがわかります。また、過剰にプロビジョニングされてリソースが無駄になっているかどうかもわかります。これは実際にはよくあるケースです。
ところで、一般的に、1 つのプロセスで 50 のリクエスト スレッドを使用することはお勧めしません。5 スレッド程度で複数のプロセスを使用する方がよいでしょう。ただし、何が最適かは、CPU にバインドされた作業を大量に実行しているかどうか、および長時間実行されるリクエストをどれだけ処理する必要があるかなど、特定のアプリケーションによって異なります。同じ Apache 経由で多数の静的ファイルを提供しているかどうかも影響する可能性があります。mod_wsgi のデーモン モードは、全体的に優れたソリューションになる可能性があります。
また、非常に古い mod_wsgi バージョンを使用していますが、これが問題を引き起こすとは考えられません。
最後に、Python の一部のサードパーティ C 拡張モジュールの問題を回避するために、これがそのサーバー上の唯一の WSGI アプリケーションである場合は、次のように設定します。
WSGIApplicationGroup %{GLOBAL}
答え2
修正しました。すべての本番サイトを独自のプロセス (およびすべての開発サイトを 1 つのプロセスにまとめて) を使用するようにデーモン モードに変換しました。Smokeping のグラフは大幅に改善されました。パフォーマンスは安定しています。
組み込みモードでこれらの問題が発生した理由についてはまだわかりません。私が知る限り、プロセスの作成/破棄は行われていませんが、少なくともサーバーの実行は改善されました。
編集:
Apache サイト構成の例:
WSGIDaemonProcess mysite12 processes=1 threads=10 display-name=%{GROUP}
WSGIProcessGroup mysite12
そして、優先度の低いサイトの場合は、次のようにしますwsgi.conf
。
WSGIDaemonProcess developmentsites processes=1 threads=15 display-name=%{GROUP}
そして、Apache conf で次の操作を実行します。
WSGIProcessGroup developmentsites
違いを見てみましょう (これも nginx プロキシによるものです):