ビジーサーバー用にDebianSqueezeでnginx + php-fpmを使用していますが、到達した最大接続数に対処するのが非常に困難でした。ここでの問題は、phpプロセスが高負荷でランダムに停止し、phpプロセスがない状態でサーバーを離れることがあることです。次に、php5-fpmサービスを手動で再起動して、サーバーを稼働状態に戻す必要があります。
これを回避する方法、または少なくとも、着信要求をリッスンするphpプロセスが残っていない場合は常にphp5-fpmを自動的に再起動することで症状を治療する方法を考えています。私の関連する設定は次のとおりです。
pm = dynamic
pm.max_children = 1400
pm.start_servers = 10
pm.max_spare_servers = 20
pm.process_idle_timeout = 1s; #not sure it will be useful when pm=dynamic
pm.max_requests = 100000
request_terminate_timeout = 30
この厄介な問題に対処するためのあなたの提案に感謝します。
古い番犬の脚本のアイデアですね。問題を解決するための最も洗練された方法ではありませんが、そもそもなぜそれが起こっているのかを理解できるまで、一時的に状況を改善することができます。
実際の問題に対処する必要があります。サーバーをより細かく調整する必要があるか、サーバーが最初から負荷を処理するのに十分な能力を備えていないかのいずれかです。
プロセスが実際に停止することを確認しました。その場合、プロセスがまだ存在するかどうかを判断するのと同じくらい簡単です。 psauxはあなたのためにそれをするべきです。
例えば:
ps aux|grep php-fpm|grep -v grep|awk '{print $2}'
php-fpmのプロセスIDを出力する必要があります。存在しない場合は再起動する必要があります
したがって、これに沿った何かがうまくいくはずです。 (短くてシンプル)
#!/bin/bash
pid=`ps aux|grep php-fpm|grep -v grep|awk '{print $2}'`
if [ $pid == '' ]
then
service php-fpm restart
fi
そのスクリプトは、毎分crontabとして実行されます。そしてそれはデバッグされていません。だからそれを試してみて、それが機能していることを確認してください。
ゾンビプロセスでそれを行うことの問題は、それらが実際に存在し、「実行中」であるが、物理的に何もしていないことです。その場合、最初にそれらを強制終了してから、プロセスを再開する必要があります。
繰り返しますが、正しいことは、サービスが実際にクラッシュする原因を特定することです。ウォッチドッグスクリプトのアイデアは、時間を購入することだけです。
それが役に立てば幸い。幸運を
Php-fcgiの問題は次のとおりです。(php-cgiとは異なり)各リクエストの後、プロセスは存続します。リクエストごとに、phpプロセスのメモリ使用量が増加します。プロセスはいつでもphpのメモリ制限に達します。
減らすことでこれを回避できます
pm.max_requests = <value>
pm.max_children = 1400
Maxchildrenパラメータをそれほど高く設定する必要はありません。それは実際には高すぎます。
あなたはそれを実験したいかもしれませんが、正直なところ:
皮切りに:
pm.max_children = 50
そしてそれがどうなるか見てみましょう。