php-fpm起動パラメータ設定の詳細説明

複数のディレクトリについて同意する必要があります

#php-fpm設定をテストする
/usr/local/php/sbin/php-fpm -t
/usr/local/php/sbin/php-fpm -c /usr/local/php/etc /php.ini -y /usr/local/php/etc/php-fpm.conf -t

#Start php-fpm
/usr/local/php/sbin/php-fpm
/usr/local/php/ sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf

#Close php-fpm
kill -int `cat /usr /local/php/var/run/php-fpm.pid`

#Restart php-fpm
kill -usr2 `cat /usr/local/php/var/run/php-fpm.pid`

2番目、php-fpm.confの重要なパラメータの詳細な説明

$ctx = stream_context_create(array(
 'http' => array(
 'timeout' => 10 //タイムアウトを秒単位で設定します
 )
));

file_get_contents( $str, 0, $ctx);

2、max_requests パラメータの設定が不適切であると、断続的な 502 エラーが発生する可能性があります。 pm.max_requests = 1000 各子プロセスが再起動される前に処理されるリクエストの数を設定します。「0」に設定すると、リクエストは常に受け入れられます。デフォルト: 0。 この設定の意味は、php-cgi プロセスによって処理されるリクエストの数が 500 に累積すると、プロセスが自動的に再起動されることです。

しかし、なぜプロセスを再起動するのでしょうか?

通常、プロジェクトでは PHP のサードパーティ ライブラリをある程度使用します。これらのサードパーティ ライブラリには、php-cgi プロセスが定期的に再起動されない場合、メモリ使用量が必然的に増加することがあります。そこで、php-fpmはphp-cgiの管理者として、指定回数リクエストを行ったphp-cgiプロセスを再起動し、メモリ使用量が増加しないように監視する機能を提供します。

同時実行性の高いサイトで 502 エラーが頻繁に発生するのは、まさにこの仕組みのせいで、php-fpm が nginx からのリクエストキューをうまく処理していないことが原因だと思われます。ただし、私はまだ php 5.3.2 を使用していますが、この問題が php 5.3.3 でも存在するかどうかはわかりません。

私たちの現在の解決策は、この値をできるだけ大きく設定して、php-cgi の再生成の数をできる限り減らし、同時に全体的なパフォーマンスを向上させることです。実際の運用環境では、メモリ リークが明らかではないことが判明したため、この値を非常に大きな値 (204800) に設定しました。誰もが実際の状況に応じてこの値を設定する必要があり、やみくもに増やすことはできません。

そうは言っても、このメカニズムの目的は、php-cgi が過剰なメモリを占有しないようにすることだけです。なぜメモリを検出して対処しないのでしょうか。 Gao Chunhui 氏の意見に非常に同意します。プロセスの内部使用量のピークを設定して php-cgi プロセスを再起動する方が良い解決策です。

3、php-fpm の遅いログ、デバッグ、例外のトラブルシューティング ツール: request_slowlog_timeout はタイムアウト パラメータを設定し、slowlog はスロー ログの保存場所を設定します。 tail -f /var/log/www.slow.log 上記のコマンドは、実行が遅すぎる php プロセスを確認できます。

プロンプト情報に従って問題をトラブルシューティングすると、過剰なネットワーク読み取りと遅い mysql クエリという一般的な問題がわかります。