PHP-FPMチルドレン WordPressでは、リクエストがスムーズに実行されるか、キューに滞留するかを決定します。不正確な pm.max_children-数値はページをブロックし、RAMを消費する。.
中心点
これ以上深入りする前に、重要なメッセージを簡単にまとめておこう：
- pm.max_children は、同時に実行される PHP リクエストの数を決定します。.
- 少なすぎる 子どもたちはキュー、502/504、高いTTFBを生成する。.
- 多すぎる RAMボトルネック、スワップ、OOMキルにつながる。.
- フォーミュラ使用可能なPHP RAM / プロセスサイズ×0.7～0.8。.
- 反復的 モニタリングによるチューニングは、長期的に最高のパフォーマンスを発揮する。.
不正なPHP-FPMの子供ページがブロックされる理由
WordPress の動的なリクエストにはそれぞれ 労働者, そして、pm.max_childrenによってプールが制御するのは、まさにこれらのプロセスである。この値を低くしすぎると、リクエストはキューにたまり TTFB が顕著に増加する。値を高くしすぎると、各子プロセスがさらにRAMを使い、サーバーはスワップに切り替わる。ApacheやNginxが502/504を報告するか、OOMキラーがプロセスを終了するまで、スワップではすべてが遅くなります。健全なスループットが達成されるのは、子プロセスの数が実際のRAM予算とプロジェクトの負荷に合っているときだけです。.
実際のpm.max_childrenの計算式
PHPで使用可能なRAMを子プロセスの平均サイズで割って、それに 安全係数 プロセスあたりのRAMは、psとRSSカラムで決定する。一般的なWordPressスタックの場合、50～250MBが正しいことが多い。4GBのサーバーでは、Linux、データベース、キャッシュサービス用にメモリーを確保し、1.5～2GBを ピーエッチピーエス のままである。例えば、プロセスの平均が100MBの場合、2,000÷100×0.75＝15childとなる。この数値は出発点であり、負荷プロファイル、キャッシュ、プラグインの組み合わせによって微調整する。.
典型的なWordPressのセットアップの開始値
2GBのRAM、8人の子供、pm = dynamic、pm.max_requestsの小さなブログの場合。 800. .RAMが4GBの中規模プロジェクトでは、childrenを12、start_serversを4、min_spare_serversを4に設定します。RAMが8GB以上の大規模ショップでは、childrenを21～40に設定すると効果的です。その後、CPUの使用率、RAMの使用率、レスポンスタイムをチェックし、微調整を行います。さらに詳しく知りたい場合は、以下のサイトを参照してください。 PHP-FPMの最適設定.
プロセスの測定：RAM要件の決定方法
水晶玉は役に立たないし、お金もかかるからだ。 パフォーマンス. .ps -ylC php-fpm -sort:rss コマンドは RSS のサイズを返します。更新中やクーロンジョブ中にプロセスが大きくなることがよくあるので、スパイクも計算に含めています。また、htopとfree -hを使って、RAMの残量とスワップの量をチェックしている。このデータを使って信頼できる平均値を割り出し、保守的な安全係数を選んでいる。.
重要なパラメータの一覧
pm.max_children に加えて、他のプールオプションは WordPress がどの程度きれいにリクエストを処理し、どの程度メモリを解放するかを決定します。 安定性 pm.max_requestsは、Xリクエスト後にプロセスを再起動することで、メモリの肥大化を防ぐ。このセットで、実際の実用的なケースの90パーセントをカバーできる。.
| パラメータ | 機能 | ワードプレスのおすすめ |
|---|---|---|
| 午後 | プロセス制御モード | 負荷が変動する場合はダイナミック、恒常的にトラフィックが多い場合はスタティック |
| pm.max_children | 最大同時作業者数 | 使用可能なPHP RAM / プロセスサイズ × 0.75 |
| pm.max_requests | プロセスのリサイクル | 300～1,000ドル。WooCommerceではむしろ低くなる。 |
| リクエスト終了タイムアウト | 長期にわたるリクエストのキャンセル | ハンガーに対して60～120秒 |
ダイナミック、オンデマンド、スタティック - どのモードが適しているか？
私は負荷プロファイルに合わせてモードを選択する： ダイナミック というのも、アクティブなプロセス数をフレキシブルに調整するので、ほとんど何もしていないときにRAMを節約できるからだ。. 静的 私は、負荷が一定で、レイテンシーやスループットに関して厳しいコミットメントが必要な場合に使用している。. オンデマンド は、アイドルフェーズの長いサーバーに適している：プロセスは必要なときだけ作成され、非アクティブになると再び終了する。トレードオフはコールドスタートで、新しいプロセスごとの最初のリクエストは遅く感じます。オンデマンドでは pm.process_idle_timeout ダイナミックであれば、（10-20秒など）クリーンなプレーができる。 スタートサーバー, min_spare_servers そして max_spare_servers プールがすぐに膨張しないよう、きつく締める。.
プールの設定例
Debian/Ubuntuでは、プールファイルは通常/etc/php/8.x/fpm/pool.d/www.confの下にあります。 構造 をカスタマイズしている。私はpmをダイナミックに設定し、pm.max_childrenに現実的な値を設定し、予備のサーバーをタイトに保っています。初期段階でリークとRAMの増加に上限を設けるため、リサイクルを500に設定しました。各変更の後、さらに値を増やす前に負荷をテストし、ボトルネックを塞ぐ。制限値に関する背景情報については、以下のサイトが詳しい。 pm.max_children を最適化.
pm = 動的
pm.max_children = 15
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500
リクエスト終了タイムアウト = 90s
複数のプール、ソケット、クリーンな断熱材
複数のプロジェクトや役割が明確に分かれている場合（フロントエンドと管理者／REST）には、次のように設定する。 セパレートプール を独自のユーザーとソケットで作成する。こうすることで、各プールはそれ自身の子プールを制限し、1つの異常値が他のプールをブロックすることはない。ホスト上では Unixソケット TCP (listen = /run/php/site.sock) - より低レイテンシ、より少ないオーバーヘッド。私はNginx/ApacheとPHP-FPMの間でTCPを使用しています。私は リストの所有者, listen.group そして listen.mode 一貫性を保ち、必要であれば、それを高める listen.backlog 短時間の負荷ピークで接続エラーが発生しないようにするためです。専用の管理者プールを使うことで、よりタイトな接続を実現できる。 リクエスト終了タイムアウト ドライブと pm.max_requests キャッシュに強いフロントエンド・プールを減速させることなく、より低い速度を実現する。.
症状を認識し、正しく対応する
エラーログに „server reached pm.max_children “と定期的に記録されている場合、プールは パラレリズム それを適度に増やしている。502/504が発生し、同時にスワップ使用率が高い場合は、pm.max_childrenをリセットし、pm.max_requestsを下げます。RAMの使用率が低いのにCPUの使用率が高い場合は、クエリーやPHPのロジックがブロックしていることが多い。データベースとキャッシュを最適化します。リクエストがスタックする場合は、より厳しいrequest_terminate_timeoutとタイムスタンプによるログ解析が役立ちます。私は、cronjobs、検索インデックス、管理者のアクションに対して顕著なピークをチェックします。.
FPMの状態とスローログ：正確な診断
を起動させる。 ステータス プールごとに(pm.status_path)、以下のような主要な数値を読み取ります。 アクティブプロセス, 最大児童数, リスナーキュー そして 最大待ち行列 off.永久に増え続けるリストキューは、明らかに、子プロセスが少なすぎるか、バックエンドがブロックされていることを示している。また リクエスト_スローログ_タイムアウト (例：3-5s）と スローログ-パス。このようにして、しばしば外部HTTPコール、複雑なWooCommerceクエリ、画像操作など、もたもたしているリクエストのスタックトレースを見ることができます。これは catch_workers_output ワーカーからの警告はログに収集される。このデータに基づいて、並列性を高めることが役に立つのか、コード/DBのボトルネックを解決する必要があるのかを判断する。.
モニタリング：3～5日間の清浄度評価
チューニング後、数日間にわたって負荷のピークを観測する。 変動 を欺く。FPMステータスでRAM、スワップ、502/504、TTFB、アクティブなプロセス数を記録している。スワップなし、キューなしのRAM使用率が80パーセント以下であれば、私は正しい。チェックアウト、検索、インポートなどのアクション中にボトルネックが発生した場合は、特にpm.max_childrenとpm.max_requestsを調整します。各ステップは小さな調整と新しい測定で行われます。.
メモリ計算の詳細：RSS、PSS、共有メモリ
プロセス変数は厄介だ： RSS (Resident Set Size）には、OPcacheやライブラリなどの共有セグメントも含まれる。そのため、単純に「RSS×Children」で計算すると、すぐにRAM消費量を過大評価してしまう。それよりは ピーエスエス-共有メモリーを各プロセスに公平に分配する - smemのようなツールはここで役立つ。この計算には以下が含まれる。 オペキャッシュ (例：256MB＋ストリングス）、, APCu (例えば64-128MB)とマスタープロセス。PHPの メモリリミット 個々のピークは発生するかもしれないが、平均値はカウントされる。私は、スパイク、デプロイメント、cronjobsが即座にスワップのトリガーにならないようにバッファを計画する。 pm.max_requests メモリの肥大化を抑える。.
WordPress特有の負荷を軽減
キャッシュのヒット率を上げれば、実時間を節約できるからだ。 RAM. .フルページキャッシュはPHPリクエストを劇的に削減し、チェックアウト、検索、管理用の容量を作成します。memory_consumptionが256MBのOPcacheはバイトコードを高速化し、プールを解放します。実際には、私はPHPのmemory_limitを256Mに保ち、個々のプラグインがサーバーの速度を落とさないようにしています。ボトルネックに関するより詳しい情報は、以下のガイドを参照してください。 PHPワーカーのボトルネック.
データベースとキャッシュ・バックエンドのバランス
すべての PHP ワーカーは潜在的に データベース接続. .pm.max_childrenを増やすと、同時DB負荷も増えます。そこで、MySQL/MariaDBをチェックしてみた： 最大接続数, バッファ (innodb_buffer_pool_size) とクエリプランナーです。Redis/Memcachedは並列で維持しなければなりません。 maxclients, メモリの制限とレイテンシー。20のアクティブな子を持つWordPressインスタンスは、いくつかの高価なクエリが並行して実行されている場合、簡単にDBを飽和させることができます。そのため、私はDBをチューニングし（インデックス、低速クエリ）、次のように設定します。 永続オブジェクトキャッシュ, をリリースします。これにより、バックエンドに負荷をかけることなくスループットを向上させることができます。.
WooCommerce、Cron、Admin：特殊なケース
そのため、私は次のようなものを使っている。 空気 を使っている。同時に、メモリの肥大化を継続的に抑えるために、pm.max_requestsを下げる傾向にあります。インポートやcronjobについては、追加予算を計画するか、ピーク時間外にタスクを実行します。管理エリアはしばしば急なスパイクを起こします。ここではキャッシュによる保護は少ないので、効率的なプールコントロールが重要です。キューの兆候があれば、スモールステップで増加させ、直後にメトリクスを監視する。.
コンテナ、vCPUクォータ、OOMトラップ
コンテナやVMでは、次のような点に焦点が当てられている。 効果的 RAMの制限(cgroups)であって、ホスト上ではない。そのため、pm.max_childrenは „free -h “ではなく、割り当てられた上限から計算します。コンテナOOMは容赦なく、カーネルはプロセスを激しく終了させる。CPUクォータもカウントされる：1-2個のvCPUで計算時間が制限されるなら、子プロセスを増やしても意味がない。経験則として、私はIOの多いWordPressのワークロードをvCPU数の2-4倍程度にスケールする。これ以上だとコンテキストスイッチは増えるが、実際のスループットは増えない。オーケストレーションされた環境では、変更を控えめにロールアウトし、ポッドの再起動を観察し、FPMの短いウォームアップ・フェーズが失敗としてカウントされないように、可読性／可用性プローブを維持する。.
見落としがちなエラーの原因
多くの問題はプールに起因しているのではない。 プラグイン, リクエストを増やしたり、長いプロセスを生成したりするインデックス検索、クローラーのルール違反、過剰なハートビート間隔が負荷を高める。そのため、私は常に最初にログ、クエリモニタ、キャッシュヘッダをチェックします。特定のURLでのみ負荷が発生する場合、私はこれをプラグインやテンプレートのボトルネックの兆候と解釈します。このような問題が解決してから、私は子どもたちの規模をさらに拡大します。.
セッション、管理AJAX、ロックを理解する
WordPress/プラグインは、部分的に セッション. .ファイルベースのセッションロックは、リクエストを直列化することができます - 1つの遅いリクエストは、同じセッションIDの残りをブロックします。私はセッションの使用量を抑えておき、管理画面のAJAXバースト（wp-admin/admin-ajax.php）が不必要に頻繁に発生していないかチェックします。そうでなければ、付加価値なしに負荷を発生させます。ロックや長いファイルアクセスが発生する場合、並列処理を増やしても効果はありません。キャッシュ、より高速なストレージI/O、または別のセッションハンドラが役立ちます。ログを見ると、異常に長い実行時間で同時に開始される多くの類似したリクエストから、 このようなパターンを認識できます。.
Nginx、Apache、FastCGIのタイムアウト一覧
ウェブサーバーも制限値を設定しているので、FPMの値と調和させなければならない。 チューニング. .Nginxでは、fastcgi_read_timeoutと十分なワーカープロセスに注意を払う。Apacheでは、mpm_event、keepalive設定、プロキシタイムアウトをチェックします。これらの制限が適切でない場合、FPMにはまだ容量があるにもかかわらず、ユーザはタイムアウトを報告します。標準化されたタイムバジェットにより、クライアントから PHP までの経路が一貫したものになります。.
ロールアウト戦略、テスト、運用
pm.max_childrenへの変更を段階的に展開し、実際の負荷の下でテストしています。FPMのリロード（グレースフル）は、接続を切断することなく設定を引き継ぎます。より大きなジャンプの前に、ピーク(例えばセール開始)をシミュレートし、以下を観察した。 リスナーキュー, CPU、RAM、レイテンシとエラー率の95～99パーセンタイル。なぜこのような値が選ばれたのかを後のメンバーが理解できるように、仮定を文書化します。スワップ＞0、ステータスの „max children reached“、502/504の増加、DBのレイテンシについてはアラームを設定した。こうすることで、数ヶ月後にトラフィックやプラグインの構成が変わっても、プラットフォームが安定したままであることを保証している。.
簡単にまとめると
誤った設定 ピーエッチピーエフピーエム-childrenはキューかRAMの制限でWordPressを遅くする。私はプロセスサイズを決定し、システムサービス用にメモリを確保し、pm.max_childrenをbufferで設定します。そして、負荷プロファイルに従って、pm.max_requests、request_terminate_timeout、モードpm = dynamicかstaticかをチェックします。キャッシュ、OPcacheとクリーンなプラグインはPHPリクエストの数を顕著に減らします。これらのステップを一貫して実行すれば、ページのレスポンスとサーバーの信頼性を保つことができます。.
