パフォーマンス分析にPHP-FPMステータスページを活用する

プールに関するステータスページに表示される内容

PHP-FPMのステータスページでは、特定の プール 処理されたPHPリクエスト：アクティブなプロセスや空きプロセスの数、リクエストが待機中かどうかなどが含まれます。ただし、これはアプリケーションが実際にPHP-FPMによって処理されていることが前提となります。コマンドラインで表示されるPHPバージョンだけでは、これや担当するFPMサービスのバージョンを特定することはできません。

したがって、まず使用されているFPMのバージョンと、Webサーバーがアプリケーションを転送するプールを特定してください。 これには、使用されているUnixソケットまたはTCPリスナー、および該当する仮想ホスト内のルーティングが含まれます。この割り当ては、後で行われるステータス照会が誤って別のプールを参照してしまうことを防ぐために重要です。

サーバーが複数のプールを運用している場合、表示される情報は問い合わせたプールに限定され、すべてのPHPアプリケーションに自動的に適用されるわけではありません。共有ホスティングでは、プールやWebサーバーの設定を行う権限がない可能性があります。その場合は、プロバイダーがステータスページや同様の指標を保護された状態で提供してくれることを頼りにするしかありません。

「呼び出し」とは、まず第一に スナップショット: 2回のクエリの間に短い待ち行列が発生したり、消えたりすることがあります。その他の値はFPMの起動以降のイベント数をカウントしており、再起動時にはリセットされます。そのため、有意義な推移を把握できるように、値とともに取得時刻とプールIDも保存してください。

このページでは、ブラウザでの待ち時間のすべてを説明しているわけではありません。ネットワーク、Webサーバー、データベース、および外部サービスも応答時間に影響を与える可能性があります。したがって、これはPHP-FPMプールの診断の出発点であり、Webサイトの完全なパフォーマンステストではありません。

ワーカーとプロセスマネージャーの理解

プロセスマネージャーは、プールがワーカーをどのように割り当てるかを決定します。 static その数は変わらない。 dynamic 設定された範囲内で、必要に応じて数を調整します； ondemand 必要に応じてプロセスを起動します。したがって、どの程度の空き容量が見込めるかは、設定された動作モードにも左右されます。

アクティブなプロセスが現在リクエストを処理中であり、空きプロセスが処理の準備ができています。アクティブなワーカーの数が多いからといって、必ずしも問題とは限りません。プールがフル稼働している場合、リクエストを迅速に処理できるからです。ただし、リクエストが待機状態にあり、応答時間が長くなり、利用可能な空きプロセスがほとんどない状況であれば、この現象はより重要な指標となります。

一時的に予備が枯渇したとしても、それだけでは恒久的な供給不足の証拠にはなりません。繰り返し行われる引き出しを、設定された値と比較してください。 プロセス制限 および、ユーザーが実際に遅延を実感する時間帯。これにより、一時的な負荷のピークと、繰り返し発生する過負荷とを区別しやすくなります。

ワーカーの数を増やせば、より多くのリクエストを並行して処理できるようになりますが、追加のメモリが必要となり、データベースや外部サービスへの負荷が高まる可能性があります。多くのプロセスが同じ低速な依存関係を待っている場合、上限値を高くしても根本的な原因は解消されません。したがって、設定を変更する前に、リソースとリクエストの所要時間を確認してください。 pm.max_children 変更する。

ホスティング・スタックにおける責任範囲を整理するには、以下の比較が参考になります。 NGINX Unit と PHP-FPM. これはアーキテクチャの視点に補足となるものです。具体的なステータス値やプロセスマネージャーの設定については、引き続き実際に使用されているFPMプールで確認する必要があります。

ステータスへのアクセスとFastCGIのセキュリティ対策

ステータス出力には、リクエストやリソースに関する機密情報が含まれる可能性があります。特に、プロセスの詳細にはリクエストURIが含まれている場合があり、そこから呼び出された関数や送信されたパラメータを推測される恐れがあります。したがって、このページは一般公開用のステータスダッシュボードではなく、診断用アクセスとして扱ってください。

制限する HTTPアクセス 内部からのリクエスト、または明示的に指定されたクライアントのIPアドレスに対して。プロキシが介在している場合は、Webサーバーが実際にどのアドレスをクライアントとして認識しているかを確認してください。この保護措置はステータスページのルーティングに適用される必要があり、公開前に確認を行うべきです。

それとは関係なく、 FastCGIへのアクセス 自身で設定する必要があります。Unixソケットの場合は所有者と権限が重要であり、TCPの場合はネットワークバインド先と許可されたクライアントを確認する必要があります。Webサーバーでのロック設定は、信頼性の低いネットワークから個別にアクセス可能なFastCGIポートを保護するものではありません。

PHPプロジェクトは、FPMのステータス出力におけるXSS脆弱性をCVE-2026-6735として公開しました。 修正済みのバージョンには、PHP 8.4.21 および 8.5.6 が含まれます。その他のバージョンブランチやディストリビューションパッケージについては、表示されているバージョン番号だけで保護されているかどうかを判断するのではなく、それぞれのセキュリティ状況やバックポートされたパッチを確認してください。

アップデートを行ってもアクセス制限は解除されません。修正されたステータスページであっても、引き続き運用上の詳細が漏洩する可能性があります。HTTP アクセスとリスナーの両方を、想定されたユーザー範囲に限定し、今後のルーティング変更の際には、これら 2 つの保護層を考慮に入れてください。

ステータスページを保護された状態で公開する

まず、対象のアプリケーションを処理しているFPMプールがどれか、またWebサーバーがどのソケットまたはTCPアドレスを介してそのプールにアクセスしているかを確認してください。複数のプールが存在する場合、ステータス照会は、それが転送されたプールに対して行われます。 コマンドラインで表示されるPHPのバージョンだけでは、そのアプリケーションを担当しているFPMサービスがどれであるかは判別できません。

該当するプールの設定ファイルにおいて、以下の抜粋は ステータスパス. これは、ドキュメントディレクトリに作成する必要があるPHPファイルではありません。この抜粋は設定の例であり、プール設定を編集できる権限があることが前提となっています。

pm.status_path = /fpm-status

Webサーバー上で、このパスへのリクエストをFastCGI経由で特定されたプールに直接転送する適切なルートを設定してください。通常のアプリケーションルーティングがリクエストをインターセプトしないようにしてください。 HTTPアクセスを内部リクエストまたは既知のクライアントIPアドレスに制限し、それとは別に、権限設定やネットワークバインディング、および許可されたクライアントを通じてFastCGIソケットを保護してください。

正式なロールアウトの前に、お使いの環境で定められた検証手順に従って、WebサーバーとFPMの両方の設定を確認してください。変更対象が正しいサービスおよびプールであること、またアクセス制限がステータスパスに対しても適用されていることを必ず確認してください。 単にパスを設定しただけでは、HTTP経由で出力にアクセスできるようにはなりません。

すでに設定済みでローカルで保護された環境の場合、以下のターミナルコマンドはJSON出力を読み取ります。このコマンドを実行するには、指定されたアドレスで適切なローカルHTTP仮想ホストにアクセスできることが前提となります。 そうでない場合は、アドレスやホストのルーティング、必要に応じてTLS設定を自分の環境に合わせて調整する必要があります。この取得操作によって設定が変更されることはありません。

curl --fail --silent --show-error 'http://127.0.0.1/fpm-status?json'

応答では、特にプール名を確認してください。エラーメッセージや予期しないアプリケーションの出力は、ルーティングの設定が適切でないことを示している可能性があります。また、アクセス制限によって取得が妨げられている場合もあります。その場合は、安易に保護設定を解除するのではなく、該当するWebサーバーの設定とログを確認してください。

主要指標の正しい読み方と計算方法

ステータス値は、さまざまな期間を表しています。取得時点の状態を示すものもあれば、イベントの回数をカウントするものや、起動以来の最大値を記録するものもあります。診断を行う上では、単一の異常値よりも、こうした区別の方が重要です。以下の表に、主要な情報を整理しました。

の場合 接続率から2つの値を引く accepted conn 互いの値を差し引き、その差を経過時間で割る。 仮定に基づく計算例（実測値ではありません）：60秒の間にカウンターが12,000から12,600に増加した場合、1秒あたりの平均接続数は10回と仮定されます。ただし、この数値からページビュー数やアプリケーションのレイテンシを直接導き出すことはできません。

各測定ポイントごとに、時刻とプールIDを保存してください。FPMの再起動後、ステータス値はリセットされるため、この切り替えをまたぐ差分は有効なレートとはみなされません。カウンタの減少または開始時刻の変更を検知したら、新しい期間について計算を再開してください。

時点では max children reached プロセスマネージャーが鍵となります。PHP 8.4.21 の設定例では、dynamic および ondemand のカウンターについて説明されています。static の場合、ゼロ値を空き容量の証拠として解釈してはなりません。 slow requests しきい値とスローログを適切に設定する必要があります。しきい値によって、どの長いリクエストが記録の対象となるかが決まります。

出力形式とプロセスの詳細を比較する

短縮版は、プール全体の概要を把握するのに適しています。フォーマットを選択する際には、値を手動で読み取るのか、それとも監視システムを通じて定期的に処理するのかが重要な判断基準となります。パラメータ full 出力にプロセスの詳細を追加するものであり、独立した交換フォーマットではない。

PHPマニュアルには、XMLやHTMLについても記載されています。自動取得を行う際は、特定のフィールドやプロセスの詳細に依存する前に、実際にインストールされているFPMのバージョンとその出力を確認してください。特に、OpenMetricsと full 個々のプロセスデータを一律に前提とするのではなく、独自のバージョンで確認する。

仝 リクエスト期間 フル版では、単位はマイクロ秒で表示されます。アクティブなプロセスでは、これは現在処理中のリクエストの所要時間を示し、非アクティブなプロセスでは、最後に処理されたリクエストの所要時間を指します。したがって、アイドル状態のワーカーでこの値が高いからといって、そのワーカーが現在そのリクエストを処理中であるとは限りません。

フィールド last request cpu そして last request memory 実行中のプロセスについては、クエリの完了後に評価が行われるため、結果はゼロとして出力されます。したがって、これらのゼロ値は、CPU やメモリの消費がないことを示すものではありません。繰り返しクエリを実行することで、プロセスが長時間実行され続けているかどうかを確認することはできますが、完全なアプリケーショントレースの代わりにはなりません。

待ち行列と処理の遅いリクエストの調査

もし 待ち行列 多くのプロセスがアクティブで、空きプロセスがほとんどない状況が繰り返し発生する場合、プールが飽和状態にあるという仮説は妥当である。単一の呼び出しだけでは判断材料として不十分だ。複数の時点を比較し、その際にクエリの応答時間が同時に増加しているかどうかに注意を払う必要がある。 キューの最大値だけでは、現在リクエストが待機中であるかどうかは判断できません。

FPMログ、CPU使用率、利用可能なメモリ量と、その期間の状況を照らし合わせて確認してください。データベース、キャッシュ、外部サービスも考慮に入れてください。PHPが遅い依存関係を待機している場合、追加のCPUリソースだけでは問題が解決しないにもかかわらず、ワーカーは稼働し続けたままになります。 ステータスページには使用状況は表示されますが、その原因を確実に特定できるわけではありません。

目立つフェーズの間に、保護されたフル出力を繰り返し取得する。 同じアクティブなプロセスでリクエスト時間が長引いている場合は、ワーカーが長時間稼働していることを示している可能性があります。その際はプロセスの状態を確認してください。プロセスが非アクティブな場合、その時間は最後のリクエストの時間を指すことになります。PID、URI、スクリプトは照合の助けにはなりますが、完全なトレースにはなりません。

特にフロントコントローラーの場合、同じスクリプト名が多くの異なるアプリケーション機能をカバーすることがあります。したがって、この観察結果に、アプリケーションのトレースと、適切に設定された スローログ。その閾値によって、どの長いリクエストが対象となるかが決まります。エントリがないからといって、すべてのリクエストが高速だったとは限りません。出力をより詳細に分類する方法については、以下の記事で解説しています。 PHP-FPMのスローログの分析.

照合を行う際は、時間枠と影響を受けたプールを記録しておいてください。そうすることで、例えば、処理が遅いデータベースクエリが、使用中のワーカーの稼働時間帯と一致しているかどうか、あるいはキューがそれ以前にすでに増加していたかどうかを確認できます。相関関係を把握することで検索範囲を絞り込むことはできますが、具体的なリクエストの確認に代わるものではありません。

ステータスページの監視と障害

繰り返し発生する負荷のピークについては、時折行う単発のチェックよりも、定期的かつ保護された形式での取得の方が有益です。JSONは自動処理に適しています。また、インストールされているPHPのバージョンとモニタリングクライアントが互換性がある場合は、OpenMetricsも選択肢の一つとなります。 誤って異なるプールを比較してしまうことがないように、各測定ポイントについて、時刻とプールの識別子を記録しておいてください。

対処する 未閲覧のアクセス 独自のイベントとして、ゼロ値としてではなく記録してください。ギャップは、ネットワーク、アクセス保護、またはステータスサービスに起因する可能性があります。それ自体は、空のプールを占めるわけでも、アプリケーションの障害を意味するわけでもありません。したがって、後の分析でギャップが明確に把握できるよう、取得時のエラーやタイムアウトも記録しておいてください。

また、FPMの再起動後に累積カウンタがリセットされる点にも注意してください。 2つの値の差が負であっても、それは負の接続レートではない。リセット後に計算を再開し、中断された区間を考慮に入れること。また、開始時刻やプール割り当ても、このような履歴上の不連続性を把握するのに役立つ。

ステータス照会がアプリケーションと同じプールで実行されている場合、ワーカーがすべて使用中のときは、照会側で待機することができます。このような状況に対応するために、 pm.status_listen 独立して動作する内部プールを備えた、別のFastCGIリスナーです。メインプールが稼働中の間もステータス診断を可能にしますが、メインプールの処理能力を高めることはありません。

この追加のリスナーには、明示的に割り当てられた、保護されたWebサーバーのルーティングが必要です。 また、そのFastCGIへのアクセスも保護し、変更が承認された後は、実際に呼び出しによって意図したプールステータスが返されるかどうかを確認してください。これにより、ステータスデータを一般に公開することなく、診断処理を通常のアプリケーションパスから分離することができます。

所見を確認し、対策を決定する

FPMのpingとステータスページは、それぞれ異なる情報を提供します。pingは、FPMが該当するリクエストに応答しているかどうかを示すものであり、空きワーカーや待機中のリクエストに関する同等の情報は提供しません。したがって、pingが成功したからといって、アプリケーションプールの負荷状況について安心できるわけではありません。

プロセス数値がログやその他の観測結果と一致しない場合は、まずプールの割り当て、取得タイミング、および再起動の可能性を確認してください。 その後、入手可能なその他のプロセスデータや運用データと値を照合してください。差異については、直ちに原因や必要な設定変更を推測するのではなく、まずは未解決の所見として扱ってください。

繰り返し発生するフルリクエストやスローログのエントリに、同じ長時間のリクエストパターンが見られる場合は、まず影響を受けているアプリケーションパスを調査してください。一方、遅延の原因がデータベースや外部サービスにある場合は、ワーカー数を変更するよりも、それらを分析した方がより効果的である可能性があります。 重要なのは、その対策が観察された原因そのものに働きかけるものであり、単なる個々の症状に対処するだけのものではないかどうかです。

の調整 pm.max_children プールが限界まで稼働していることが確認でき、かつCPU、メモリ、および下流のサービスがさらなる並列処理に対応できる場合に、この選択肢が検討されます。ワーカー数を増やすとリソースをさらに消費することになり、これらのサービスへの負荷が高まる可能性があります。したがって、万能な数値は存在せず、プロセスマネージャーの動作モードも評価の対象となります。

変更を適用した後、可能な限り同等の負荷条件下で同じプールを再度比較してください。キュー、応答時間、エラー、リソース消費量は相互に関連しています。また、対策を実施しても改善が見られない場合や、依存関係にさらなる負荷がかかる場合も記録しておいてください。これこそが ビフォー・アフター比較 今後の対応について、根拠に基づいた決定を下すことを可能にする。