管理

PHP-FPMのモード比較：静的、動的、オンデマンド

この記事では、PHP-FPM のモードを比較します。静的, ダイナミック そして オンデマンド そして、それらがどのようにプロセスを開始し、RAMをバインドし、レイテンシに影響を与えるかを示す。どのモードが説得力があるのか、適切な開始値、典型的なつまずきの原因、モニタリングのコツなど、実践的な方法で説明します。 ピーエッチピーエス-プールを安全に使用する。.

中心点

すぐに始められるように、最も重要な記述をコンパクトにまとめる。プロセス制御、RAM要件、レイテンシー、応用分野に焦点を当てている。各選択肢には明確な長所がありますが、同時に限界もあります。いくつかの重要な数値があれば、信頼できる決定を下すことができます。そのため、集中的なアプローチが可能です。 チューニング そして時間を節約する。.

静的固定されたプロセス番号、一定の負荷で最大の一貫性。.
ダイナミック最小値と最大値の間の自動スケーリング。.
オンデマンドオンデマンド始動、経済的なアイドリング、コールドスタートの待ち時間。.
RAMプランニング1プロセスあたり20～50MBを許容し、OOMを避ける。.
モニタリングステータスページ、ログ、htopで根拠のある決断を。.

プロセスマネージャーの仕組み

PHP-FPM プロセスマネージャは 労働者-ワーカーインスタンスはそれぞれ、インタプリタや拡張機能、バイトコードの一部をメモリ上に保持する。各 Worker インスタンスはインタープリタ、拡張機能、バイトコードの一部をメモリに保持します。 メガバイト バインドされる。3つのモードは、開始時の動作、ライフサイクル、アイドル時の動作を大きく変える。Staticは一定数のアクティブを維持し、Dynamicは下限と上限の間でバランスをとり、Ondemandはリクエストを受け取ったときのみプロセスを生成する。この制御は RAM-プロファイル、電源投入時のレイテンシー、システム負荷のピーク。.

重要なパラメータは、コンフィギュレーションのバックボーンを形成します：午後はモードを定義する、, pm.max_children 限られた同時作業者のハードワークダイナミック pm.start_servers, pm.min_spare_servers そして pm.max_spare_servers バッファの幅を制御する。オンデマンドは pm.process_idle_timeout, を使用して、休止中のプロセスを再び終了させる。適切な値を設定することで、負荷のピークがボトルネックにならないようにし、マシンがメモリ不足に陥らないようにすることができる。.

1工程あたりのフットプリント、平均同時負荷、1日のピーク分布を事前にチェックする。これらの変数から、以下の最大値を導き出す。 pm.max_children に測定されたプロセス・メモリを乗じ、ウェブ・サーバー、データベース、キャッシュ、カーネル用に予備を残す。この単純な計算により、メモリ不足のエラーを防ぎ、以下のことを保証します。 安定性 プレッシャーがかかっているとき。これを肝に銘じておけば、後で再調整する手間が省ける。.

スタティック・モード：均一な負荷に対して一定の電力を供給

スタティックモードでは、固定数の PHP ワーカーが常時アクティブになります。 スタート-オーバーヘッドは排除される。一定のトラフィック・プロファイルで、このセットアップは非常に低いレイテンシ変動を達成し、一貫した CPU-ロード。欠点：アイドル状態では、リクエストがないにもかかわらずRAMが占有されたままになる。そのため、私はRAMに余裕があり、リクエスト量が計算できるホストでのみStaticを選択します。使用頻度の高いショップやAPIバックエンドでは、Staticが最もきれいなレスポンスカーブを描くことが多い。.

決定的な要因は、現実的に設定されたものである。 pm.max_children, これはプロセスのフットプリントに基づいています。最初の見積もりでは、拡張モジュールとOPcacheを含めて、PHPプロセスあたり20-50MBと計算しました。最終的な値は負荷テストとシステムモニターで検証します。さらに計算を深めたい場合は、以下のサイトで実践的な手順を見ることができる。 pm.max_children を最適化. .これにより、固定プールのサイズがハードウェアと一致するようになります。.

[www]
pm = static
pm.max_children = 50
pm.max_requests = 500

ヒント変更後、PHP-FPMを再起動し、ログをチェックし、実際のトラフィックでの使用率を観察します。RAMの空き容量がまだ多ければ、慎重に増やします。もしスワップの使用量が増えていたり、OOMキラーエントリーがあったりしたら、すぐに減らす。この小さなルーチンが 空室状況 信頼できる。

ダイナミック・モード：変動する需要に柔軟に対応

ダイナミックでは、わずか数プロセスから開始し、以下のようにスケーリングします。 労働者-を必要に応じて定義された範囲に設定します。これにより、閑散期のアイドル消費は減り、短いピークは緩和される。このメソッドは、スポーン時に若干のオーバーヘッドを発生させるが リソース-効率。日替わりプロファイルが混在する環境では、多くの場合、Dynamicが最良の妥協点を提供する。このモードは、特に多くのCMSインストレーションの最初の選択肢であり続けている。.

開始値、最小値、最大値を設定し、一般的な負荷では一定のスポーンイベントが発生しないようにした。ビジーなようだ、子供がスポーンしている」といったログメッセージが頻繁に表示される場合は、制限が厳しすぎることを示している。WordPressのスタックについては、キャッシュとOPcacheを正しく設定し、それらを適度に増やすことが役立ちます。コンパクトなガイドが最も重要なレバーをカバーしています：最適化されたWordPressの設定. .これによって、以下のような問題が発生することなく、短い応答時間を達成することができます。 RAM-リザーブ.

[www]
pm = 動的
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

チップ一日を通して、アイドル状態のワーカーと平均的なアクティブプロセスを観察する。平均値が上限に近い場合は、適度に増やします。多くのプロセスがアイドルのままなら、範囲を下げる。ほんの数回繰り返すだけで スイートスポット-設定。.

オンデマンド・モード：アイドル・モードで経済的、要求があれば始動

オンデマンドがプロセスを作成するのは お問い合わせ を実行し、アイドル時間後に終了させる。これにより、静かなフェーズでは RAM の必要量が最小になり、1 台のマシンに多数の小さなサイトがある場合に有利になります。しかしコールドスタート時には、ワーカーが最初に起動してウォームアップするため、追加の待ち時間が発生します。開発環境、cron 専用アプリ、アクセス頻度の低いページでは、このロジックは利益. .私はオンデマンドを連続的な負荷の下では使わないだろう。.

[www]
pm = オンデマンド
pm.max_children = 50
pm.process_idle_timeout = 10s
pm.max_requests = 500

私は通常、通話パターンとメモリ予算に応じて、アイドル時間を10秒から30秒の間に設定する。これより短いと RAM, しかし、コールドスタートの可能性は高くなる。期間を長くすれば、プロセスは暖かく保たれるが、メモリが犠牲になる。そのため、私はコール頻度をモニターし、95パーセンタイルのレイテンシを測定し、微調整を行っている。これにより 応答時間 システムに負担をかけることなく計算できる。.

比較表：3つのモードの特性

以下の概要は、典型的な特性を比較したものである。具体的なサイジングに入る前に、議論の基礎として使用します。この表は、実負荷での測定に代わるものではありませんが、構造化された 出発点. .値を調整する場合は、常にメモリプロファイルとレイテンシ分布に注意する必要があります。そのため ピーク そしてボトルネックを避ける。.

基準	静的	ダイナミック	オンデマンド
プロセス	固定番号、常時アクティブ	自動的に最小/最大	必要なときだけスタート
RAM使用量	常に高い	可変（例：200～600MB）	アイドルモード時の最小値（例：50～700MB）
パフォーマンス	非常に均等	優秀で適応力がある	低トラフィックに最適
こんな方に最適	常にトラフィックの多いプロフィール	可変需要	休眠サイト多数／共有
オーバーヘッド	低い	ミディアム（スポーン／デスポーン）	コールドスタートの方が高い

この表は、期待値を調整し、優先順位を明確にするのに役立つ。最大限の一貫した対応が必要な場合、多くの場合、勝者は次のようになる。静的. .変動する負荷で効率をカウントし、動作する ダイナミック 通常はもっと快適だ。経済性を優先するのであれば、これを避けては通れない。 オンデマンド オーバー。最終的に決めるのは測定値であり、仮定ではない。.

リソースの計算とサイジング

まず、以下のように プロセス を想定ワーカー数で割って、20-30個の%リザーブを追加します。また、Nginx/Apache、データベース、Redis/Memcached、カーネル用のスペースも加えます。この合計が物理的なRAM容量からセキュリティマージンを引いたものを超えてはならない。バイトコードが置き換わらないように、OPcache用の専用メモリを計画している。この単純な フォーミュラ 私はOOMリスクは低いと考えている。.

次のステップでは、ウェブサーバーのステータスとAPMを使って同時リクエストを計測する。PHPワーカーの競争のピークが、どの程度高いかを決定する。 pm.max_children でなければならない。RAMが十分でなければ、キャッシュヒットを増やすか、クエリー時間を短縮するか、仕事をキューに移す。これらのレバーが効いて初めてプールを増やす。これにより 効率性 高く、マシンは確実に反応する。.

モニタリングとトラブルシューティング

良い決断とは、次のようなものである。 データ. .PHP-FPMのステータスページを起動し、アクティブなプロセスとアイドル状態のプロセス、キューの長さ、受け入れられたコネクションを読み出す。また、エラーログでスポーン警告やタイムアウトをチェックする。htopでは、ボトルネックをより早く見つけるために、CPUの待ち時間、負荷、スワップを監視している。これらのシグナルは、チューニングのステップを わかりやすい そして、盲目的な飛行を避ける。.

<?php
$status = @file_get_contents('http://localhost/status');
$data = json_decode($status, true);
echo "Active: " . $data['active processes'] . "\n";
echo "Idle: " . $data['idle processes'] . "\n";
?>

APMツールは、関数やクエリーレベルでのトレースやボトルネックを表示する。そこで異常値を見つけたら、まずキャッシュとI/Oから始める。それから、プールの上限が実際の並列度に合っているかどうかをチェックする。アプリケーションのボトルネックが解決されたときに初めて、さらに次のことを行う価値がある。定員をFPMに組み込む。このプロセスは時間を節約し、無駄のないアーキテクチャを維持する。.

よくあるチューニングエラーを避ける

私はしばしば、高すぎる数字を目にする。 max_children-RAMに関係なく。これは、不必要なスワップ、長いガベージ・コレクション・フェーズ、ひいてはOOMキラーを生み出す。低すぎる制限値も、キューを構築して応答時間を引き延ばすので有害である。OPcacheの不足もCPU時間を浪費し、プロセスのフットプリントを増加させる。いくつかの 小切手 こういった罠は、あらかじめ邪魔にならないようにしておく。.

2つ目の典型的な例：Ondemandの不適切な時間制限は、多くのコールドスタートにつながる。10秒、20秒、30秒のアイドルタイムアウトを使った短いA/Bテストが役に立つ。一方、Dynamicでは、スペアの値が小さすぎると、常にスポーンが発生する。ログはすぐにこれらのパターンを明らかにし、次のテストに役立てる。 カスタマイズ をオンにする。これでスタックの応答性が保たれる。.

PHP-FPM と他の PHP ハンドラとの関係

PHP-FPM は、古い CGI や LSAPI のような現代的なものとよく比較されます。ハンドラの選択はプロセス管理に影響を与えます、, リソース-特性および故障隔離。この違いを理解すれば、バッファとリミットをより現実的に計画することができる。簡単な概要については、以下のページを参照されたい。 PHPハンドラの比較. .その後、FPMモードが有利であることは明らかである。 よりターゲットを絞った より。

FPMは成熟しており、ログがきれいに記録され、Nginx/Apacheとうまく動作するので、私は通常FPMにこだわっています。決定的なのはベンチマークだけでなく、観測可能性やフェイルオーバーなどの運用面も重要です。これらの基本が正しければ、Static、Dynamic、Ondemandからより多くのものを得ることができます。すべてのオプションは、実際の負荷の下でテストされるに値する。そうすることで設定.

実践的な意思決定戦略

私はダイナミックから始める デフォルト, 負荷プロファイルを測定し、ピークを観察する。利用が非常に一定している場合は、Staticに切り替え、固定プールサイズを設定します。めったに利用されないサイトがあれば、適切なアイドルタイムアウトを設定したオンデマンドを選択します。同時に、OPcache、オブジェクトキャッシュ、データベースクエリを最適化し、FPMの負荷が少なくなるようにします。そして、次のように制限を微調整します。 キュー そもそも生じない。.

この順序により、リスクと労力が軽減される。まず測定し、次にルールを適応させ、次にハードウェアを検討する。私はそれぞれの変更について、時間、値、目標を簡潔に文書化する。こうすることで、後で修正するのが簡単になり、クリーンな状態を保つことができる。 透明性. .これにより、トラフィックパターンが変化しても、スタックを管理しやすい状態に保つことができる。.

主要数値から信頼できる値まで：私はこうして計算する

私は単純な経験則を使って、負荷プロファイルを具体的なプール・サイズに変換しています。1秒間に何件のリクエストが届き、平均して、あるいは95パーセンタイルで、そのリクエストの処理にどれくらいの時間がかかるか？私は次のことを目安にしている。 リトルの法則 を単純化すると、同時処理≒スループット×平均処理時間となる。例：120リクエスト/秒、平均80ミリ秒の場合、同時実行数は約9.6となる。ピーク用に30-50個の%バッファを追加し、その結果、同時実行数が約9.6回になるかどうかをチェックする。 pm.max_children がRAM予算に収まる。ハードピークの場合は、キューを避けるために95パーセンタイルも含める。.

重要なのは キャラクター ワークロードのI/Oの多いアプリ（リモートコールやDBアクセスが多い）では、ワーカーが少し多い方が待ち時間が重なるので有利なことが多い。CPUを多用するコードでは、プロセスが互いに遅くならないように、またランキューが爆発しないように、多めに制限する。.

pm.max_requests: フラグメンテーションに対するクリーンなリサイクル

長く実行されている PHP プロセスは フラグメンテーション またはメモリリークが増大する。と pm.max_requests を定義することで、処理されたリクエストの数だけワーカーを終了させ、再起動させることができます。これによってフットプリントが安定します。拡張機能やコードベースにもよりますが、私は通常 300-1000 から始めます。プロセスの RSS/PSS 値を観察してください：もし大きくなったら、値を減らします。OPcacheは シェアード バイトコードはワーカーのリサイクル中も保持されるため、ほとんどのアプリはリサイクルにほとんど気づかない。.

[www]
頻繁に再起動することなく的を絞ったリサイクルを行う
pm.max_requests = 800

日頃から展開プールの再読み込みから恩恵を受ける。私は 優雅なリロード サービスマネージャ経由で (たとえば „systemctl reload php-fpm“) 実行中のリクエストをきれいに終了させ、新しいワーカーは更新された設定で開始するようにします。.

スローログとタイムアウト：ボトルネックの可視化

ほとんどの待ち時間のピークは、いくつかの遅いリクエストによって引き起こされる。したがって、私は スローログ を適度なしきい値（例えば2～5秒）で設定し、スタックトレースを見る。こうして問題のある関数や外部呼び出し、高価なクエリーを見つけるのだ。.

[www]
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/slowlog-www.log

これに合わせて タイムアウト を使用します。上流のタイムアウト (Nginx/Apache) が PHP の max_execution_time に比べて短すぎると、502/504 エラーが発生します。ウェブサーバーの接続、読み込み、送信のタイムアウトは、一般的な PHP のリクエスト時間より少し上、かつ上限を超えないようにします。.

キュー、バックログ、ステータス値の正しい解釈

FPMのステータスの中で、私が特に注目しているのは„リスナーキュー“と„最大待ち行列“.これらの値が定期的に増加する場合、プールが小さすぎるか、ブロックされている。短期的なピークは正常だが、恒久的な輻輳はサイズ不足を示す。激しくバーストする環境では、ソケットバックログ 適度にキューを見て、カーネルの制限（例えばsomaxconn）がボトルネックになっていないことを確認する。.

もしモニタリングで „busy seems, spawning children “が頻繁に表示されるようであれば、リザーブパラメータ(Dynamic)が厳しすぎます。オンデマンドでは、コールドスタートの割合が高い場合は、アイドルタイムアウトを延長するか、日中のバッファを最低限に保つことをお勧めします。.

複数のプール：公平性、分離、クォータ

マルチテナントまたは共有-ホストでは、アプリケーションをそれぞれのプールに分け、個別に制限を設けている。これにより、メモリを大量に消費するプロジェクトが他のプロジェクトを圧迫するのを防いでいる。クリティカルなサービス（ログイン/APIエンドポイントなど）については、最小リザーブを固定した専用プールを計画する。明確なネーミング（„www-shop“、„www-api“、„www-cron“）と個別のログは、データの分析と管理を容易にする。 エラーを検索する。.

を合計したものであることを確認する。 pm.max_children はすべてのプールでマシンにフィットする。また 下流リミット についてDB-最大接続数, Redis/Memcachedのスレッドと外部APIのレート。データベースが処理できる以上のクエリを同時に実行する PHP プールは、キューを長くするだけです。.

OPcacheのウォームアップ、プリロード、コールドスタートに対応

宛先 オンデマンド-コールドスタートを軽減するために、私はOPcacheを安定した状態に保っている。 メモリ消費 そして interned_strings_bufferに設定する。 プリロード 中央のクラス／フレームワーク。これは、バイトコードが最初のヒット後に利用可能になり、繰り返しがウォームなままであることを意味する。さらに、より大きな realpath キャッシュと構造化されたオートローダは、ファイルシステムのルックアップを減らすのに役立ちます。全体として、これは新しく起動したワーカーの起動時間を大幅に短縮します。.

ウェブサーバーとの対話： Nginx/Apacheをクリーンに接続する

ウェブサーバーとFPMの設定が一致していることを確認しています：バッファと タイムアウト は対称でなければならず、keep-alive はゾンビ接続で FPM をブロックしてはならず、上流のソケット (Unix または TCP) は一貫して設定されていなければならない。502/504 エラーの多くは、正しく設定されていない読み込みタイムアウトや使い果たされたバックログが原因となっています。TCP 経由で FPM を使用する場合は、ネットワークスタックの待ち時間や セミオープン 接続に注意してください。私は通常、ローカルの展開にはUnixソケットを好みます。.

コンテナ/VMの特殊機能

コンテナでは cgroup-ホストの値とは限りません。私は、コンテナRAM用に明示的にプールの寸法を決め、人工的な負荷ピークを使用して、OOMキラーが効果を発揮するかどうかをテストしている。厳しすぎる制限は、ハードキャンセルを引き起こす。コンテナの入れ替えも望ましくないことが多い。 pm.max_children アプリケーションのキャッシュを計画し、優先順位をつける。.

CPUとI/Oキャラクタの認識

私はhtop/iostatを使って、ワークロードが適切かどうかを評価している。 CPU- またはI/Oバウンドしている。CPU使用率が高く、I/O待ちが少ない場合は、計算負荷が高いことを示している。高いI/O待ち時間は、データベース、ネットワーク、ファイルシステムでの待ち時間が重なっているため、ワーカーを増やすことが正当化されます。ワーカーを増やしても待ち時間は減少せず、負荷が大幅に増加することで限界を認識できます。.

典型的な502/504パターンを素早くデコード

504 ゲートウェイのタイムアウト：Web サーバーのタイムアウトが PHP の実行時間未満、またはプールがブロックされている（キューが満杯）。.
502 Bad gateway: FPM に到達できない (ソケット/ポート)。.
デプロイ直後のスパイク：OPcacheのコールド、オートローダー/コンポーザーの最適化のチェック、ウォームアップのスケジュール。.

私は、ウェブサーバーのエラーログ、FPMのエラーログ、ステータスページを同じタイムウィンドウで関連付けています。これによって、問題が発生する前か、発生中か、発生後かがわかる。への FPMがある。.

貿易の測定：保管コストを正しく記録する

RAMプランニングのために、私はRSSを見るだけでなく、次のことも見ている。 ピーエスエス (比例セットサイズ）は、分割ページ（OPcacheなど）をプロセス間で公平に分配するからだ。以下のようなツールもある。 スメム や pmap は、現実的なプロセス関連値を決定するのに役立つ。しかし、実際には、負荷のかかったランダムなサンプルで十分なことが多い。 リザーブ 倍増 - フォーラムの理論値よりも現実を反映している。.

迅速な反復のためのミニ・チェックリスト

負荷プロファイルを記録する（RPS、50/95/99パーセンタイル、並列性）。.
プロセスのフットプリント（RSSだけでなくPSS）を測定し pm.max_children 遠慮なく。.
パターンに合わせてモードを選択します：スタティック（一定）、ダイナミック（変化）、オンデマンド（アイドル時間が多い）。.
pm.max_requests セット後、作業員の成長を観察し、必要であれば再調整する。.
コールドスタートを抑制するために、OPcacheを拡張し、ウォームアップ／プリロードをチェックする。.
ステータスページとスローログをアクティブにし、キューとスポーンメッセージを分析する。.
ウェブサーバーのタイムアウトとバッファをFPMとアプリの時間と同期させる。.
下流システム（DB、キャッシュ、外部API）との制限の調和。.
変更を文書化し、デプロイ後に測定し、反復する。.

コンパクトな概要

静的最もスムーズなレスポンスタイムを実現し、大容量のRAMを備えたコンスタントなトラフィックに適しています。. ダイナミック 柔軟性と効率性のバランスが取れており、変化するパターンにも対応できる。. オンデマンド は、アイドル時にメモリを節約し、多くの休眠サイトに適していますが、コールドスタートのレイテンシーという代償を伴います。クリーンなリソース計算、モニタリング、小さな繰り返しにより、信頼性の高い決定を下すことができます。プロセスを必要なだけ小さくし、OPcacheを使用し、実際のニーズに合ったモードを選択してください。 プロフィール フィットする。

これらのガードレールがあれば、合理的な消費で安定したパフォーマンスを達成できる。コンフィギュレーションは、数字がテーブルの上にあるとき、当てずっぽうのゲームではない。小さなステップが最大の効果を発揮することが多い。測定し、調整し、文書化する。そうすれば、あなたの ピーエッチピーエフピーエム-プールを素早く、経済的に、予測可能にする。.