PHP-FPM のキャパシティプランニング：ワーカー、RAM、同時リクエスト数の算出

PHP-FPM ワーカーの制限事項

PHP-FPM は、PHP プロセスをプール単位で管理します。1つの 労働者 それぞれ1件ずつリクエストを処理します。プールの設定は pm.max_children 同時に利用可能なワーカーの数を制限し、それによってこのプールで同時に処理されるPHPリクエストの数を制限します。複数のプールが存在する場合、この制限は各プールごとに適用され、サーバー全体に自動的に適用されるわけではありません。

この数値は、ログイン済みの訪問者数でもなければ、1秒あたりのリクエスト数の直接的な値でもありません。1人の訪問者が複数のリクエストを発行する可能性がある一方で、ログイン済みのユーザーは2つの操作の間、ワーカーを占有することはありません。逆に、1つの処理に時間がかかるリクエスト1件が、連続する複数の短いリクエストよりも長くワーカーを占有する場合もあります。

また、すべてのページアクセスがPHP-FPMに到達するわけではありません。Webサーバーが静的ファイルを直接配信する場合や、上流のキャッシュがリクエストに完全に応答する場合、アーキテクチャによってはPHPワーカーは必要ありません。 一方、キャッシュミス、ログイン済みのユーザー、管理ページなどは、依然としてPHPリクエストを生成し、一時的にリソース使用率を上昇させる可能性があります。

したがって、キャパシティ計画においては、2つの別々の問いが重要となります。それは、「利用可能なRAMに、予備を含めて何人のワーカーを収容できるか？」、そして「プールに実際に到着するトラフィックに対して、リクエストが過度に長く待機しないようにするには、何人のワーカーが必要か？」というものです。高い値は pm.max_children これらの質問のどれにも、単独では答えられない。

十分なメモリが確保されていても、CPU、データベース、または外部サービスによって実質的な処理能力が制限される場合があります。その場合、ワーカーを追加すればPHP処理の並列実行数は増えますが、同時に、すでに処理速度が低下しているサービスへの負荷をさらに高める可能性があります。したがって、プールの値は運用上の制限であり、パフォーマンスを保証するものではありません。

プロセスマネージャーとキューの理解

仝 プロセスマネージャー PHP-FPM がワーカーを割り当てるタイミングを指定します。 static 保持されているプロセス数は、次の値に相当します。 pm.max_children。これにより、処理件数を十分に計画しやすくなりますが、負荷が低い場合でもリソースを占有してしまいます。上限値自体は、利用可能なストレージ容量に見合うものでなければなりません。

時点では dynamic FPMはプロセス数を調整します。開始数、および空きワーカーの最小数と最大数も別途設定されます。 ondemand ワーカーは必要な場合にのみ生成され、設定されたアイドル時間経過後に終了します。これにより、利用頻度の低いプールではリソースを節約できますが、突然の負荷のピーク時には、まず新たな処理能力を確保する必要があります。

すべてのワーカーが稼働中の場合、それ以降の要求は リスナーキュー 空きプロセスを待つ。FPMステータスには、現在のキューと最大キューなどが表示される。ただし、単一の最大値が高いからといって、そのプールが現在過負荷状態にあるかどうかは判断できない。それを判断するには、時間的な基準が必要となる。

キューが大きくなっても、ワーカーが追加されるわけではなく、動作の遅いデータベースの速度が向上するわけでもありません。キューはリクエストを一時的に受け入れることはできますが、待ち時間を単にPHP処理の前に繰り上げるだけなのです。したがって、プロセスマネージャーを選択する際には、通常の負荷の推移だけでなく、短時間のピークが及ぼす影響も重要になります。

Workerメモリの適切な配置

ワーカーのメモリ使用量は、PHPの設定制限値だけから確実に推測することはできません。計画立案には、適切な負荷条件下でのプロセスデータの方が役立ちます。その際、個々のプロセスの常駐メモリを確認する場合と、PHP-FPMワーカーのグループ全体のメモリ使用量を推定する場合とでは、状況が異なります。

RSS プロセスの常駐メモリを表します。複数のワーカーが同じメモリページを共有している場合、それらのページはそれぞれのRSSに含まれることがあります。すべてのワーカーのRSS値を合計すると、共有されているページが場合によっては重複してカウントされるため、その合計値だけでは、共有されている物理メモリの正確な状況を示すことはできません。

ピーエスエス 共有ページを、関与するプロセスに比例配分します。したがって、プロセスグループのメモリ割り当て計画においては、RSS値の合計よりもPSS値の合計の方が役立つ場合が多くあります。とはいえ、これはあくまでその時点の状況を示すものに過ぎません。ページを共有するプロセスの数が変われば、それぞれの割合も変化します。

一般的なリクエストだけでなく、メモリを大量に消費するリクエストについても、複数のワーカーを想定して検討してください。 起動直後のプロセスや単一の平均値だけでは、その後の需要を過小評価してしまう可能性があります。さまざまなワーカー数や負荷状態におけるプール全体のPSSを把握することで、保守的な近似値を導き出すことができます。ただし、共有部分とプライベート部分の割合が変動するため、ワーカー数を増やした場合の予測は不確実です。

PHPのmemory_limit これは、FPMプロセスのオペレーティングシステムメモリ全体に関する信頼できる指標ではなく、この観察結果を置き換えるものではありません。OPcacheなどによって共有されているメモリについては、使用中のプールPSSにすでに比例配分されて含まれている場合、一律に予算から再度差し引くべきではありません。 ただし、その他のサービスや予備容量については、依然として考慮に入れる必要があります。

RAMの予算とワーカー数を計算する

出発点は、実際に利用可能なRAMです。ホスト上ではサービスに利用可能なメモリ、コンテナ内では有効なメモリ制限となります。そこから、オペレーティングシステム、Webサーバー、必要に応じてローカルデータベース、およびその他のサービスに必要なメモリを差し引きます。 他のFPMプールや、使用量の変動に備えた予備分も、この計算に含める必要があります。

残りの割合は、 プール予算. ワーカーの推定値については、さまざまなプロセス数や負荷状態におけるプール内のワーカーのPSS合計値を観察します。一般的なリクエストだけでなく、メモリを大量に消費するエンドポイントも考慮に入れてください。 それぞれの合計値を、対象となるワーカー数で割り、複数の観測結果から慎重な近似値を導き出してください。

以下の計算は、あくまで説明のための例であり、実際の測定結果ではありません。使用されている値は、計算手順を示すためのものであり、特定の用途に対する推奨値ではありません。結果は、ワーカー数の整数部分に切り捨てられます。

25人のワーカーは、確実に確保される保証はありません。PSSは共有ページを比例配分し、そのページを共有するプロセスの数に応じて変化します。また、リクエストの構成が異なれば、プライベートメモリの要件も変化する可能性があります。したがって、推計値は、観測された総消費量および設定された上限値と照らし合わせて確認する必要があります。

OPcacheのような共有メモリが、使用されているPSS合計にすでに比例配分されて含まれている場合は、それを改めて一括して完全な追加項目として差し引かないでください。 とはいえ、分析の対象外となるメモリ使用分については、予備として余裕を持たせておく必要があります。特にコンテナ制限の場合、最終的には推定されるワーカーの合計だけでなく、制限範囲内のすべてのプロセスの使用量がカウントされるからです。

起動したばかりのワーカー単体では、判断材料としてあまり意味がありません。まだ負荷の高いリクエストを処理していない可能性があるからです。 そのため、複数の時点を比較し、それぞれの時点でどのエンドポイントが関与し、いくつのワーカーが関与していたかを記録してください。そうすることで、選択した近似値が、不利ではあるものの現実的な運用状況においても有効であるかどうかを判断することができます。

リクエストから必要なワーカー数を推定する

RAM計算では、予想されるワーカーの収容数を算出します。 一方、実際の需要を算出するには、対象となるプールに実際に届くPHPリクエストの数と、それらがワーカーを占有する時間を考慮する必要があります。大まかな目安として、平均同時稼働ワーカー数は「1秒あたりのPHPリクエスト数」に「ワーカーの平均占有時間（秒）」を乗じた値となります。

説明用の計算例であり、実測値ではありません：1秒あたり20回のPHPリクエストがあり、平均処理時間が0.25秒であると仮定すると、平均して5人のワーカーが稼働しています。これは、対象期間における平均値です。 これは、常に正確に5つのプロセスが稼働しているということでもなければ、短時間のピーク時において5つがプールの上限として十分であるということでもありません。

リクエスト数については、すべてのページビューを無条件にカウントしてはいけません。キャッシュがPHPを呼び出さずに多くのレスポンスを返す場合、これらのヒットはプールに負荷をかけません。 逆に、キャッシュミスやログイン済みの訪問者、管理用アクセスなどは、1日を通じた平均値から予想されるよりも、一時的に多くのPHP処理を引き起こす可能性があります。

仝 作業員の作業時間 これには、処理中の待機時間（データベースや外部サービスへのアクセス待ちなど）も含まれます。これは、ブラウザに表示される応答時間と必ずしも同一とは限りません。以下によると、 fastcgi_finish_request() PHPは、クライアントへの応答をすでに完了しているにもかかわらず、ワーカー内でさらに処理を実行し続けることができます。

許容可能な待ち時間を実現するには、平均稼働率を上回る余裕が必要です。その余裕の大きさは、負荷の変動、処理速度の遅いエンドポイント、および目標とする応答時間などによって決まります。 1秒あたりのピークリクエスト数に高いレイテンシパーセンタイルを乗算することは、慎重なシナリオ検証にはなりますが、正確なキュー予測とはなりません。

したがって、複数の時間帯を個別に検討する必要があります。短時間のピーク時と静かな夜間交通では、より均一な運行の場合と同じ1日の平均値になることがありますが、求められる要件は異なります。 バックエンドの処理速度が遅いために処理時間が長くなると、到着率が同じであっても、拘束されているワーカーの平均数も増加します。したがって、需要は単に訪問者数の特性だけによるものではありません。

計画からプールの設定を導出する

次に、RAMに基づく上限値と、余裕を含めた推定必要量を比較してください。必要量がその下にある場合は、 pm.max_children、予算をすべて使い切る必要がない場合です。この例で言えば、25 が計算上の RAM 上限となりますが、必ずしも適切な設定とは限りません。CPU やバックエンドによって、それ以前に制限がかかる可能性があります。

推定される要件がRAMの上限を超える場合、上限を引き上げても矛盾は解消されません。むしろ、ホストやコンテナにメモリ負荷がかかる可能性があります。 逆に、制限値が極端に低いと、リクエストが待機状態になる可能性があります。その場合は、実行時間やキャッシュの利用率を改善するなどして、追加のリソースや入力負荷の制限が必要かどうかを確認してください。

時点では ダイナミック 上限値に加えて、起動数、および空きワーカーの最小数と最大数を設定します。 初期値と予備値は、予想される負荷に見合ったものにし、上限値の範囲内に収める必要があります。予備容量が少なすぎると、突発的な負荷が発生した際に追加の起動が必要になる可能性があります。一方、常に多くの空きプロセスがあると、リソースを消費してしまいます。

時点では オンデマンド ワーカーは必要な場合にのみ生成され、終了までのアイドル時間は個別に設定されます。これは使用頻度の低いプールでは有効ですが、負荷が急激に増加する場合は特に注意が必要です。ここでも制限が設けられており、 pm.max_children プール内で同時に利用可能なワーカーの数。

同じホスト上の複数のウェブサイトは、それぞれが独立して利用可能なRAMの全量を割り当てられるわけではありません。各サイトのプール上限値を、他のサービスや予備分と合わせて予算を策定してください。 必要に応じて設定されたグローバルなFPMプロセス制限が追加で適用される場合がありますが、これは個々のプール予算や、CPUおよびデータベースの容量チェックに代わるものではありません。

変更後は、初期値を最終的なものと見なすのではなく、適切な期間にわたって実際の負荷状況や待ち時間を確認してください。 マネージドホスティングの場合、プロセスデータやプール設定に直接アクセスできない可能性があります。その場合は、プロバイダーが提供するメトリクスや公開されているオプションを活用してください。また、利用可能な設定は、PHPのバージョンや動作環境によっても異なります。

FPMの状態とメモリの使用状況を監視する

FPMステータスページでは、実際の負荷下で計画されたワーカー数が十分かどうかを確認できます。 ステータスエンドポイントを保護する 一般からのアクセスには注意：リクエストやリソースに関する機密情報を漏洩する可能性があります。別途設定されたステータスリスナーは、メインプールが負荷過多の状態でもアクセス可能なままにしておくことができます。お使いのPHPバージョンやWebサーバーの設定に合わせて、その可用性と設定を確認してください。

これらの値を次のように考えてください 時系列 問い合わせ件数や応答時間と併せて。 キューの過去の最大値は、現在の過負荷を証明するものではありません。同様に、カウンターについても、前回の観測以降の上昇幅は、単なる合計値よりも意味があります。その際、参照期間が変更されるプールの起動や再起動を考慮に入れてください。

既知のFPMワーカーについては、procインターフェースが利用可能なLinuxシステム上で、集約されたメモリ値を読み取り専用で取得できます。以下の部分を置き換えてください PID 実際のプロセスIDによって；これには適切なアクセス権限が必要です。単一のプロセスから恒久的なプールサイズを推測するのではなく、複数のワーカーや負荷状態について同様の観察を繰り返してください。

cat /proc/PID/smaps_rollup

処理の遅いリクエストとキューの調査

PHPの実行自体が本来のボトルネックではないにもかかわらず、ショップでは多数のアクティブなワーカーが表示されることがあります。 リクエストがデータベースの処理が遅いために待機している間、ワーカーはその間拘束されたままになります。さらにリクエストが到着すると、CPUにまだ余裕がある場合でも、リスナーのキューが長くなり、応答時間が長くなる可能性があります。

このような状況では、ワーカーの上限を引き上げることで、データベースに同時に送信されるリクエストの数が増える可能性があります。これにより、 バックエンド印刷 が増加し、待ち時間がさらに長くなる可能性があります。そのため、制限値を引き上げる前に、FPMの使用率と待機列の推移を、データベースの負荷、クエリの処理速度の低下、および外部サービスへの呼び出しと照らし合わせて確認してください。

FPMのSlowlogは、実行時間が長いPHP呼び出しを特定するのに役立ちます。設定された閾値を超えるリクエストに対して、FPMはバックトレースを記録できます。これは実行ポイントを示すものであり、リクエスト全体に関する完全なプロファイルではありません。 繰り返し発生する箇所については、リクエスト時間やバックエンドのメトリクスと照らし合わせて確認できます。 PHP-FPM スローログの分析手順 さらなる分析について解説します。

タイムアウトも、実際の容量とは区別する必要があります。nginx では、 fastcgi_read_timeout FastCGIサーバーによる連続した読み取り処理間の許容間隔であり、リクエスト全体の所要時間を一律に指すものではありません。この値を大きく設定すると、待機時間が長くなる可能性がありますが、ワーカーが追加されるわけでも、データベースの処理が高速化されるわけでもありません。

処理能力の限界と今後の対応

RAMの予算が見積もられた必要量に足りない場合、 pm.max_children この相反する課題には注意が必要だ。追加のプロセスも同様にメモリを消費する。その代わりに、PHPリクエストの数を減らすか、ワーカーの占有時間を短縮できるかどうかを検討してほしい。どの対策が適切かは、観測された負荷がどこで発生しているかによって異なる。

キャッシュを効果的に活用すれば、繰り返し行われるリクエストを処理できるほか、PHPの実行やデータベースへのアクセスが高速化されることで、ワーカーをより早く解放できるようになります。適切なバックグラウンド処理は、直接的なリクエストパスから切り離すことができますが、こうした処理にも独自のリソースが必要となります。 負荷制限はピーク時のバックエンドを保護しますが、その結果、リクエストが待機状態になったり、拒否されたりすることがあります。

メモリが実際に決定的な制約となっている場合、RAMを増設することでワーカー数を増やすことが可能になります。ただし、CPU、データベース、または外部サービスがすでにフル稼働している場合は、それらの処理能力も考慮に入れる必要があります。したがって、メモリを増やすだけでは、応答時間の短縮やスループットの向上が保証されるわけではありません。

個々のワーカーのメモリ使用量がそのライフサイクルを通じて増加する場合、 pm.max_requests それらを定期的に置き換えるように手配してください。これは、サードパーティ製ライブラリのメモリリークに対処する際に役立つ場合がありますが、その根本原因を解決するものではありません。変更後も引き続きプールメモリやリクエストの挙動を監視し、再起動メカニズムをデバッグの代わりとして扱わないようにしてください。

より広範なアーキテクチャ上の決定を行うためには、 NGINX Unit と PHP-FPM の比較 背景：NGINX Unitはアーカイブ化されており、もはやメンテナンスされていません。選択したアーキテクチャにかかわらず、変更は 時系列 確認：同程度のリクエスト量において、キュー、ワーカーの負荷、メモリ、および応答時間を比較してください。これにより、調整によってボトルネックが実際に解消されたのか、それとも単に別の場所にシフトしただけなのかを判断できます。