max_children=40、各子は平均 20M ～ 30M のメモリを占有します。子の数が増えると、同時に受け入れられる同時実行数も増えます。通常、子の値は、Web サイト上の同時実行数の最大値 + 変動値になります。この値は、必要なメモリ使用量×メモリ使用量になります。
max_requests = N は、各子が N 個のリクエストを受け入れた後、自身を強制終了し、子を再確立することを意味します。
PV / max_children = 各子が受け入れたリクエストの数 [デフォルトでは、ブラウズごとに PHP プログラムを 1 回だけ呼び出します。おそらく非同期的に呼び出されます。インターフェースはどうですか? ]
たとえば、上記の値が 1000 で、10240 を定義すると、fpm が子を強制終了して再構築するのに 10 日以上かかります。メモリ リークがある場合、プロセスは大量のメモリを占有し、実行できなくなります。が解放されると、fpm の処理能力が低下し、不可解なエラーが発生します。
しかし、この値を小さすぎると、fpm は頻繁に子を強制終了して再構築することになり、追加のオーバーヘッドも発生します。
もちろん、最善の最適化は、常にデバッグを行い、Web サイトの運用に基づいてバランス ポイントを見つけることです。
max_children への遅延アプローチもあります php が 5.3 の場合は、fpm のスタイルを apache に似たものに設定できます。このとき、子の数は fpm によって自動的に制御されます。対応する設定パラメータは次のとおりです。
start_servers: 開始プロセスの数
min_spare_servers: プロセスの最小数
max_spare_servers: プロセスの最大数
サーバーが比較的アイドル状態の場合、fpm はリソースを節約するためにいくつかの冗長な子をアクティブに強制終了します。サーバーがビジー状態の場合、サーバーは自動的にさらに子を作成します。
########################
Nginx 502 Bad Gateway は、要求された PHP-CGI が実行されたものの、何らかの理由 (通常はリソースの読み取り）が完了せず、PHP-CGI プロセスが終了します
一般的に、Nginx 502 Bad Gateway は php-fpm.conf の設定に関連しています。
php-fpm.conf には 2 つの重要なパラメータがあります。1 つは max_children で、もう 1 つは request_terminate_timeout ですが、この値は普遍的ではないため、自分で計算する必要があります。
502 問題は、通常、デフォルトの php-cgi プロセスが 5 であるために発生します。phpcgi プロセスが不足していることが原因である可能性があります。/usr/local/php/etc/php-fpm を変更する必要があります。 max_children 値は適切に増加します。
計算方法は次のとおりです:
サーバーのパフォーマンスが十分に高く、ブロードバンド リソースが十分で、PHP スクリプトに無限ループやバグがない場合は、request_terminate_timeout を直接 0s に設定できます。 0 の意味は、PHP-CGI を時間制限なく実行し続けることを意味します。これができない場合、つまり、PHP-CGI にバグがある可能性がある場合、帯域幅が十分でない場合、またはその他の理由で PHP-CGI がフリーズする場合は、次のことを推奨します。 request_terminate_timeout の値。この値はサーバーのパフォーマンスに応じて設定できます。一般に、パフォーマンスが優れているほど、20 分から 30 分の範囲で高く設定できます。
そして、max_children の値はどのように計算されるのでしょうか?原則として、値が大きいほど、php-cgi プロセスが速く処理され、キューに入れられるリクエストが少なくなります。 max_children の設定もサーバーのパフォーマンスに応じて設定する必要があります。通常、サーバー上の各 php-cgi が消費するメモリは約 20M です。
公式の回答に従って、関連する可能性を確認し、ネチズンからの回答と組み合わせて、次の解決策を考え出しました。
1. php fastcgi のプロセス数を確認します (max_children の値)
コード: netstat -anpo | grep "php-cgi" wc -l
5 (5 が表示されている場合)
2.
コード: top
fastcgi プロセスの数を観察します。使用されているプロセスの数が 5 以上の場合は、増やす必要があることを意味します (マシンの実際の状況に応じて)
3. /usr/local/php/etc/php-fpm.conf 関連設定
request_terminate_timeoutの実行時間は60秒、つまり1分です。
##############################################
ウェブサイト動作環境はNginx +php fastcgiモードです。ここ数日動作が不安定で、常にエラーが発生し、502エラーが報告されています。
今日、元同僚にアドバイスを求めたところ、php-fpm ログを確認するように言われました。そこには多くの有益な情報が記録されています。
そこで確認してみると、確かにたくさんのエラー メッセージがあることがわかりました:
Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200
もしそうならnginx.conf :worker_rlimit_nofile 65500; 不整合をチェックし、サービスを設定して再起動する必要があります
Mar 01 14:39:15.881047 [通知] fpm_children_make()、行 352: child 12364 (プールのデフォルト) が開始されました
Mar 01 14:39: 21.715825 [通知] fpm_got_signal() 、行 48: SIGCHLD を受信しました
Mar 01 14:39:21.715899 [通知] fpm_children_bury()、行 215: 子 11947 (プールのデフォルト) は開始から 175.443305 秒後にコード 0 で終了しました
一部エラー メッセージの説明は簡単です。情報をオンラインで直接確認してください。
検索後、最終的に次の最適化戦略をまとめました:
1. サーバーのファイル ハンドルを増やして開きます
# vi /etc/security/limits.conf plus
* ソフト nofile 65500
* ハード nofile 65500
2. nginx の開いているプロセス ファイルの数を増やします
nginx.conf: worker_rlimit_nofile 65500;
3. php-fpm.conf ファイルを変更する必要があります。主な変更は 2 つあります。
コマンド ulimit -n を使用して、開いているファイルの制限された数を確認します。php-fpm.conf のオプション rlimit_files がこの値と一致していることを確認します。
4,
# vi /etc/sysctl.conf
に
を追加します一番下の fs.file-max=65500
上記の変更後、PHP を再起動します。 /usr/local/webserver/php/sbin/php-fpm restart
ulimit -n が有効かどうかを確認します。そうでない場合はサーバーを再起動するか、/etc/sysctl.conf と /etc/security/limits.conf の設定が有効になります。
今のところ上記のエラーメッセージはまだ出ていません。すべてがうまくいきます。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
