コンテンツにスキップ 
PHP のリクエストキューは、サーバーが同時に処理するリクエストの数を制限し、 応答時間やエラー率、ユーザーエクスペリエンスを決定します。以下にその方法を示します。 加工限界 そして、ボトルネックを解消し、調和されたパラメーターによって一貫したデリバリーを実現する。.
中心点
すぐに始められるように、最も重要な調整ネジをまとめておこう。 ピーエッチピーエフピーエム 一緒にね。
- pm.max_childrenPHPの同時プロセスの上限をRAMに合わせて計算します。.
- listen.backlogピーク負荷時の接続試行の短期バッファリングを最大化する。.
- pm.max_requestsメモリリークや肥大化を避けるため、定期的にプロセスをリサイクルする。.
- タイムアウト: request_terminate_timeout、max_execution_time、Webサーバーのタイムアウトを一貫して設定します。.
- 指標max childrenに達した場合、リッスンキューとスローログを継続的にチェックする。.
私は、明確な数値と測定可能な効果に重点を置いている。 限界 は追跡可能なままです。変更のたびに、次のステップを計画する前にログとレスポンスタイムをモニターし、徐々に値を増減させていく。こうすることで、メモリのスワッピングのような副作用を防いでいる。 キュー 劇的に長くなる。このアプローチで、私は負荷のピークをコントロールし、レスポンスタイムを安定させている。目標は、バランスの取れた稼働率を達成することである。 リソース ホストに過負荷をかけることなく、効率的に。.
PHP-FPM における PHP リクエストキューイングの仕組み
各 HTTP リクエストは 労働者, で、ワーカーは一度に一つのリクエストにしか応じない。全てのプロセスがビジー状態の場合、それ以上の呼び出しは キュー を作成し、プロセスが空くまで待つ。このキューが大きくなると、応答時間が長くなり、502/504のようなエラーが頻発する。そのため私は、やみくもに最大並列度にこだわるのではなく、プロセス数と利用可能なメモリとの賢明な比率に注意を払っている。こうすることで、以下のような問題が発生することなく、一定のスループット率を達成している。 RAM あるいはCPUが離脱する。.
プロセスマネージャーモードをきれいに選択する
限界値に加えて pmモード 応答性とリソース消費：
- pm = ダイナミックstart_servers、min_spare_servers、max_spare_serversを定義しています。このモードは、負荷の増加に素早く反応し、ウォームなプロセスを準備させておくので、負荷が変動する場合の私の標準だ。.
- pm = オンデマンドプロセスは必要な時にのみ生成され、process_idle_timeout後に終了します。これにより、アクセス頻度が低い場合（管理、ステージング、cronエンドポイント）はRAMを節約できますが、急激なピーク時にはRAMが失われる可能性があります。 コールドスタート そしてより高いレイテンシー。そのため、私は厳選し、余裕を持ったバックログで使用している。.
- pm = static固定プロセス数。理想的なのは ハード上限 そして特に予測可能なレイテンシ（例えば、少数の、しかし重要なエンドポイントの前にあるL7プロキシ）。RAMの必要量は明らかに計算可能だが、未使用のプロセスはメモリを圧迫する。.
私は、各プールのプロファイルに適したモードを決める。私は通常、負荷が変化するフロントエンドにはダイナミック、ユーティリティプールにはオンデマンド、レイテンシが重要な専用サービスにはスタティックを使う。.
pm.max_childrenを正しく決定する
最も重要なレバーは pm.max_children, なぜなら、この値は同時に実行できるリクエスト数を定義するからである。経験則から開始サイズを計算します：(自由に使える RAM - 2 GB の予備) を PHP プロセスあたりの平均メモリで割った値です。大まかな仮定として、私はプロセスあたり40-80MBを使い、最初は32GBのホストで200-300プロセスから始めます。実負荷の下で、私は徐々に増減させ、PHPプロセスの待ち時間が短くなるかどうかをチェックします。 キュー が低下し、エラー率が低下する。スタート値とリミット値についてさらに詳しく知りたい場合は、以下のサイトを参照されたい。 pm.max_children を最適化.
スタート値、スペア値、バックログ値の調整
をセットした。 pm.start_servers をpm.max_childrenの15-30%程度に設定することで、開始時に十分なプロセスが利用でき、コールドスタートがないようにします。pm.min_spare_serversとpm.max_spare_serversで、新しいリクエストが待たないように、また同時に不必要なアイドル時間がメモリを使い果たさないように、空きプロセスの妥当なウィンドウを定義します。Listen.backlog は特に重要です：このカーネルバッファは、全てのワーカーがビジー状態の時に、追加の接続試行を一時的に保持します。負荷のピークには高い値 (例えば 65535) を設定します。 待ち行列 は FPM プールの前では停止しない。ウェブサーバ、アップストリーム、バッファ間の相互作用に関するより詳細な背景情報は、以下の概要を参照してください。 ウェブサーバーのキューイング.
リクエスト実行時間の制限とプロセスのリサイクル
私は、忍び寄るメモリサージを pm.max_requests, これは、Xリクエスト後にすべてのプロセスを再起動させる。メモリリークが疑われる場合は、100-200に減らして効果を観察する。さらに、request_terminate_timeoutは、極端に長いリクエストを一定時間後に終了させることで、異常値をカプセル化します。一貫性は重要です。PHPのmax_execution_timeとWebサーバーのタイムアウトを同じ回廊に保ち、片方のレイヤーがもう片方より早く終了しないようにします。この相互作用によって 労働者 を解放し、混雑からプールを守る。.
キューを可視化ログとメトリクス
私は定期的にFPMのログを読み、次のことに注意を払っている。 最大児童数, なぜなら、このエントリーはプロセスの上限に達したことを示しているからである。同時に、リスン待ち行列を監視し、入力バッファのバックログが増加していることを明らかにする。request_slowlog_timeoutと組み合わせて、コード内の遅いポイントのスタックトレースを取得し、データベースやAPIのブレーキを切り分ける。ウェブサーバーのログからupstream_response_timeをrequest_timeやステータスコードと関連付け、長い応答時間の原因を絞り込む。これにより、PHP-FPMがボトルネックになっているのか、APIがボトルネックになっているのかがわかる。 データベース または上流ネットワーク。.
ワークロードプロファイル：CPUバウンドとIOバウンド
CPUを多用するプロセスでは、次のようにスケールします。 パラレリズム プロセスを増やしてもスループットはほとんど上がらないので、私は慎重に、vCPU数に忠実な運用を心がけています。データベースアクセスや外部APIによるIO負荷が主であれば、RAM予算が十分である限り、プロセスを増やしても構わない。Eコマースのチェックアウトは、キャンセルなしで支払い方法を完了するために、より長いタイムアウト（例えば300秒）が有効です。listen.backlogを高く設定し、予備ウィンドウを増やすことで、フラッシュセールを阻止している。プロセス数とホスト性能のバランスに関する情報は、以下のガイドにまとめられている。 ボトルネックとしてのPHP-Workers.
計算例と寸法
私はまず、プロセスあたりのメモリを計算し、それから賢明な方法を導き出した。 上限 オフ。それから実際の負荷でテストし、キューが減ってスループットが上がるかどうかを観察する。開始値を控えめにすることで、スワッピングのリスクを減らし、レスポンスタイムを均一に保つことができる。その後、副作用に確実に気づくために、少しずつ改良していきます。以下の表は、開始値とスループットへの影響に関するガイダンスである。 キュー.
| パラメータ | 効果 | スタート値（例） | ヒント |
|---|---|---|---|
| pm.max_children | 最大同時発音数 プロセス | 200-300（32GBの場合） | RAM予算とプロセスサイズとの比較 |
| pm.start_servers | 当初の労働者数 | 15-30 % max_childrenより | コールドスタートは避け、アイドリングは最小限に抑える。 |
| pm.min_spare_servers | 無料 労働者 最低限 | z.B. 20 | 新規リクエストを直接取り込む |
| pm.max_spare_servers | 自由労働者の上限 | z.B. 40 | アイドルプロセスのRAM消費を制限する |
| listen.backlog | 接続試行用のカーネル・バッファ | 65535 | ピーク負荷を緩和し、接続の中断を減らす |
| pm.max_requests | リサイクル インターバル | 500-800、漏れあり100-200 | メモリの肥大化とハングアップの最小化 |
| リクエスト終了タイムアウト | ハードリクエスト制限 | 300-600 s | PHPとWebサーバーのタイムアウトの整合性 |
PHP FPM プールの実用的なテンプレート
リードアクセスが多い店では、私は適度に設定する。 プロセス数値 を追加し、 リクエストがキューに並ばないように予備ウィンドウを増やします。NGINXまたはApacheが静的コンテンツを効率的に配信する限り、キャッシュを使用するコンテンツページでは、かなり少ないワーカーで十分なことが多い。私は、メモリプロファイルが異なるアプリケーション部分に応じてマルチプールのセットアップを分離し、重いプールが他のプールを置き去りにしないようにしています。cronやキューワーカーのために、独自のタイムアウトルールを持つ別々のプールを定義しています。こうしてインタラクティブな トラフィック 無料であり、ユーザーの動作を遅らせることはない。.
ウェブサーバーのタイムアウト、アップストリーム、ソケット
からのFastCGIとプロキシのタイムアウトを考慮する。 Nginx や Apache を FPM のタイムアウトと同じウィンドウで処理することで、 どのレイヤも早く終了しないようにする。両方のサービスが同じホスト上で動作している場合は、TCP よりも Unix ソケットの方が望ましい。分散セットアップの場合は、安定したキープアライブ値と十分に大きなコネクションプールを持つTCPを使用する。並列性が高い場合、nginx は worker_connections と FPM のバックログ値を同期します。これにより、リダイレクトが高速に保たれ、接続が厳しすぎることによるアイドル時間を避けることができます。 上流-制限がある。.
レバーとしてのキャッシュ、OPCacheとデータベース
私は、高価なオペレーションを減らし、最小化することで、多くのサーバーの問題を解決している。 応答時間 より低い。私はOPCacheのスイッチを入れ、キャッシュのメモリ制限を適切に増やし、高いキャッシュヒット率を確保します。PHPの処理がより早く完了するように、アプリケーション・キャッシングを使用しています。データベース側では、遅いクエリを最適化し、使用するシステムに適したクエリ・キャッシュを有効にします。1ミリ秒節約するごとに、データベースへの負荷が軽減されます。 キュー で、ワーカー1人あたりのスループットを向上させる。.
安全な緊急メカニズムと再起動
起動させる 緊急再起動のしきい値 と emergency_restart_interval を設定することで、 あまりに多くの子プロセスが立て続けにクラッシュした場合に FPM マスタが再起動するようにしています。この制御された再起動によって連鎖反応を防ぎ、サービスを利用可能な状態に保つことができる。同時に、エスカレーションを防ぐために、メモリとプロセス数に明確な制限を設けている。アップストリーム側のヘルスチェックは、自動的にプールから欠陥のあるバックエンドを削除し、エラー率を下げる。これにより 空室状況 実際の原因を調査する間.
オペレーティング・システムとsystemdの制限を微調整する
だから listen.backlog カーネルの制限を調整する。OSの値net.core.somaxconnは、少なくとも設定されたバックログと同じ高さでなければならない。許可されるファイル記述子の数もチェックする：FPMプールではrlimit_files、サービスレベルではLimitNOFILE（systemd）、カーネルレベルではfs.file-maxを設定します。 ウェブサーバーも、すぐに制限に達しないように、同様の予備が必要です。.
より安定したレイテンシーを得るために、私は vm.swappiness, これは、カーネルがアクティブに使用されているメモリページを早期に置き換えないようにするためである。レイテンシが重要なセットアップでは、私は 透明な巨大なページ, 長いページフォールトを避けるためである。FPMがTCP経由で実行される場合は、net.ipv4.tcp_max_syn_backlogとreuse/keepaliveパラメータも同期させる。このようなOSの詳細は目立たないように思えるが、キュー スムース の有効期限が切れるか、あるいは FPM の前に接続がすでに拒否されているか。.
プロセスごとのメモリ負荷を測定
一般化された推計を行う代わりに、以下のような測定を行っている。 実質消費 実負荷時のワーカーあたりの私は ps、smem、pmap のようなツールを使って php-fpm の子プロセスをフィルタリングし、 リクエストが実行されている間の RSS の値を平均しています。共有 OPCache の使用量を考慮することは重要です: 共有メモリは複数回カウントされません。平均化された値からpm.max_childrenを導き出し、ピーク時でもマシンがボトルネックにならないように予備も計画します。 スワッピング を傾ける。
機能やリリースが変更された後は、この測定を繰り返す。新機能や依存関係の増加、フレームワークの変更によって、プロセスあたりのフットプリントが大幅に増加する可能性がある。そのため、プロセス数を現実的なものにし、キューを短くする。.
PHP FPMのステータス、ping、ライブメトリクス
状況を素早く把握するために、私は次のことを実行した。 pm.status_path そして Pingエンドポイント (ping.path/ping.response)。受理されたコネクション、リッスンキューの長さ、アイドル/ビジープロセス、到達した最大チャイルド数、およびそれらの進行状況といった主要な数値を見ることができる。リッスンキューが恒常的に増加するようなら、プロセスを増やすか、遅いリクエストの原因を取り除く。アイドルが低いまま、到達した最大子プロセスが跳ね上がる場合は、 プールが小さすぎるか、あるいは ロングラン.
また、あるエリア（APIインポートなど）でスパイクが起きても、インタラクティブ・トラフィックが膝をつくことがないように、異なるプロファイルでプールを分けている。診断的なケースでは、一時的にlog_levelを上げ、slowlogがより多くのサンプルをキャプチャするようにする。.
アップロード、バッファリング、大きなリクエストボディ
PHPが最初にリクエストボディを読まなければならない場合、大きなアップロードは不必要にワーカーを拘束する可能性がある。私はウェブサーバが バッファ (NGINX の fastcgi_request_buffering など) を使用することで、ボディが完了したときにのみ FPM が起動するようになります。これは、アップロード中にワーカーがブロックしないことを意味します。client_max_body_size、post_max_size、max_input_time を使って、エンドポイントを危険にさらすことなくリクエストの大きさと長さを制御しています。間にファイルがある場合は、バッファジャムを避けるために十分に高速なテンポラリメモリ（SSD）を割り当てます。.
非常に大きなボディを持つエンドポイント（輸出/輸入など）については、専用のプールを定義し、独自のタイムアウトを設けて並列度を下げている。これにより、標準的なワーカーは自由になり キュー 重要なユーザーアクションの.
データベース接続とプールの境界
最高のFPM設定でも、もし データベース 以前は制限されていました。PHPプロセスの最大同時実行数を、実際に利用可能なDB容量に合わせます。持続的接続や接続プールについては、すべてのプールの合計が に於いて max_connections のままです。短いクエリが多い場合、PHP の並列処理を適度に制限することで、何千ものセッション間で DB がスラッシュしないようにすることができます。.
遅いトランザクションはすぐにFPMのキューに滞留する。そこで、ロックの待ち時間、インデックスの使用状況、クエリプランを分析しています。DB のランタイムを短縮するごとに、PHP の文書期間 そして、待ち行列の長さを短縮する。.
スパイクのないリリースとロールアウト
新バージョンを展開するときは、コールドキャッシュとプロセスの嵐を避ける。私は リロード ハードリスタートの代わりに、既存のワーカーリクエストがきれいに終了するようにします（process_control_timeout に注意）。切り替える前に一度クリティカルパスを実行したり、プリロードを行うことで、早い段階で OPCache をウォームアップします。こうすることで、多くのワーカーが同時にクラスファイルを解析するのを防ぎ 応答時間 は飛躍的に増加する。.
ブルー／グリーンまたはカナリア戦略では、徐々に負荷を上げ、ステータスページを監視する。キュー、エラー率、レイテンシが安定しているときだけ、トラフィックの割合を増やす。このコントロールされたアプローチは、デプロイ中の負荷ピークから守ってくれる。.
コンテナとVMの専門分野
コンテナでは 総貯蔵量 多くの場合、ホストのレポートよりも低い。私は、pm.max_children を cgroup の制限に厳密に合わせ、OOM キラーに対する予備を計画する。PHPのメモリ制限(memory_limit)とプロセスあたりのフットプリントは一致しなければならない。.
コンテナにスワップがなければ、ハードキャンセルの可能性が高くなる。これが、私がプロセスを保守的に保ち、リサイクルを有効にし、本番負荷のRSSピークを監視する理由だ。1つの大きな一枚岩のプールよりも、いくつかの無駄のないプールの方が堅牢であることが多い。.
制御可能な劣化と背圧
もし キュー 私は制御された劣化に頼っている。過負荷の場合、重要でないエンドポイントにはリトライ後に503を意図的に配信し、高価な機能（ライブ検索など）を減らし、ホットスポットへの並列アクセスを制限している。これにより、全ユーザーがタイムアウトに陥るのではなく、私が原因を修正する間、システムの応答性を保つことができます。.
簡単にまとめると
持参する PHPリクエストキューイング RAM予算と負荷のタイプに同時プロセス数を巧みに合わせることで、制御下にある。高いバックログ値がピークをバッファし、すべてのレベルのタイムアウトがうまく連動し、リサイクルが忍び寄るメモリの問題を取り除きます。ログとメトリクスは、キューが成長しているかどうか、どこでリクエストが滞っているか、いつ強化すべきかを示してくれる。入念な調整と的を絞ったキャッシュによって、リクエストあたりの処理時間を短縮し、スループットを向上させることができる。こうすることで、サーバーは安定したサービスを提供し、高コストなサービスを避けることができる。 タイムアウト 日常生活の中で。
