php-fpm の max_children の設定を理解する

現在、nginx fpm は基本的に主流の構成になっていますが、その中でも pm.max_chindren の構成がより重要です。

まず、次の設定に注目します。 pm = 静的/動的。

関連する学習の推奨事項: PHP プログラミングの入門から習熟まで

このオプションは、 fpm 子プロセス ：

static ： fpm の実行時に pm.max_chindren ワーカー プロセスを直接フォークすることを意味します

dynamic : は、start_servers プロセスが実行時にフォークされ、負荷に応じて最大 max_children プロセスまで動的に調整されることを意味します。

通常、静的を使用することをお勧めします。利点は、負荷状況を動的に判断する必要がなく、パフォーマンスが向上することです。欠点は、より多くのシステム メモリ リソースを消費することです。

上記は、max_chindren によって表されるワーカー プロセスの数を示しています。一般に、この構成で同時に処理できる同時実行性が高くなると考えられていますが、これは比較的大きな誤解です:

• #1) 実際には、より多くのプロセスが存在し、プロセスのコストが増加します。はい、同時に実行できる fpm プロセスの数は CPU の数を超えることはありません。より多くのワーカーを開くことで QPS が向上するというのは間違った理解であり、より多くのプロセスを開くと処理用の CPU が増えるという意味ではありません。
• 2) ワーカー プロセスが少なくなります。サーバーがビジー状態の場合、nginx がデータを fpm にヒットさせます。すべてのワーカーが動作しており、リクエストを受け入れるアイドル状態のワーカーがないことがわかります。したがって、結果は 502 になります。
• 3) 実際のビジネスでは、データベースの読み取りや内部 RPC 呼び出しなど、多くの I/O 操作が発生するため、I/O を待機している間、プロセスはシステムによってスリープ状態になります。および CPU を占有しません。構成されているワーカーの数が少ない場合、CPU は使用されません。

それでは、ワーカーの数はどのように構成すればよいでしょうか?

理論的には、ワーカー プロセスの数 = CPU の数が最も合理的ですが、ポイント 2 により、各ワーカーがリクエストの処理を完了していない可能性があるため、502 が頻繁に発生します。ただし、より多くのプロセスを開くことは、502 を回避してリクエストを一時的にハングすることを意味しますが、これはそれを軽減する方法にすぎず、実際には、これはシステムの同時実行性を高めるだけでなく、システムの負荷も増加させます。 2 と 3 に基づいて、適切な数のワーカーを設定することの方が重要です。

世界で唯一、速い武道は、プログラムの効率を可能な限り高め、一回のリクエストの時間を最小限に圧縮することです。一人のワーカーが短縮され、単位時間で処理できるようになり、当然リクエストも増えました。

そして、max_children の数は、各ワーカーが単位時間内に処理するリクエストの数によって推定できます。最大のリクエストの処理時間 (xhprof の CPU 時間) が 100 ミリ秒以内で、100 ミリ秒以内に 100 個のリクエストが同時に受信される場合、理論的には、最初にリクエストをハングするように 100 個のワーカー プロセスを構成する必要があります。

ただし、最大リクエスト時間は多くの外部環境の影響を受ける可能性があり、特にネットワーク I/O も含まれるため、推定するのが困難です。このタイプの xhprof などのサードパーティのプロファイル ツールを借用することもできます。このツールは、CPU 時間の消費をカウントできます。この期間中の実際のワーカー数を計算することは、合計時間を計算するよりもはるかに合理的です。実際、ここには max_children 数値を構成するためのショートカットがあります。これは、早い段階で max_childnren を設定することです。しばらく安定して動作させた後、fpm のステータスで 最大アクティブプロセス数 を観察し、それよりも大きくなるように max_children を設定すれば問題ありません。

以上がphp-fpm の max_children の設定を理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。