PHP-FPMのログについて

2026年7月5日

PHP-FPMのログとは、PHP-FPM自体の動作状況や、PHPアプリケーション実行時のエラー、処理に時間がかかっているリクエスト、ワーカープロセスの状態などを確認するためのログです。

Nginx + PHP-FPM構成では、Nginx側のアクセスログやエラーログだけでは、PHP内部で何が起きているのかまでは分からないことがあります。

たとえば、以下のような問題が発生したとします。

サイトが急に重くなった
502 Bad Gatewayが出る
504 Gateway Timeoutが出る
WordPressやLaravelがたまに落ちる
PHPのFatal errorが発生している
PHP-FPMのプロセス数が足りていない
メモリ不足でPHP-FPMのworkerが落ちている

このような場合、PHP-FPMのログを確認することで、原因をかなり絞り込めます。

PHP-FPMログは、Webサーバー側の問題なのか、PHP側の問題なのか、DBや外部APIが原因なのかを切り分けるために非常に重要です。

PHP-FPMの基本的な役割

PHP-FPMは、PHP FastCGI Process Managerの略です。

NginxやApacheなどのWebサーバーからPHPの処理を受け取り、PHPスクリプトを実行する常駐プロセスです。

Nginx + PHP-FPM構成では、リクエストの流れはおおむね以下のようになります。

ユーザー
  ↓
Nginx
  ↓ FastCGI
PHP-FPM
  ↓
PHPアプリケーション
  ↓
DB / Redis / 外部API など

Nginxは静的ファイルの配信やリクエストの受付を担当し、PHPの実行はPHP-FPMに渡します。

そのため、Nginxのログだけを見ても、PHPアプリケーション内部のエラーや遅延原因までは分からないことがあります。

PHP-FPMのログを見ることで、PHP側で何が起きているのかを確認できます。

PHP-FPMで確認すべき主なログ

PHP-FPM関連で確認すべきログは、主に以下の4種類です。

ログの種類	主な用途
PHP-FPM error log	PHP-FPM本体やpool、workerの状態を確認する
PHP error log	PHPアプリケーション実行時のエラーを確認する
PHP-FPM slowlog	処理が遅いPHPリクエストを確認する
PHP-FPM access log	PHP-FPMが処理したリクエスト単位の情報を確認する

それぞれ役割が異なります。

特に重要なのは、以下の3つです。

PHP-FPM error log
PHP error log
PHP-FPM slowlog

サイトが遅い、502や504が出る、PHPが落ちる、といったトラブルでは、まずこの3つを確認すると原因を追いやすくなります。

PHP-FPM error log

PHP-FPM error logは、PHP-FPM本体の動作状況を記録するログです。

PHPアプリケーションのエラーというより、PHP-FPMのmaster process、pool、worker processに関するログが中心です。

PHP-FPM error logに出る主な内容

PHP-FPM error logには、以下のような内容が出力されます。

[05-Jul-2026 12:34:56] NOTICE: fpm is running, pid 1234
[05-Jul-2026 12:34:56] NOTICE: ready to handle connections
[05-Jul-2026 12:35:10] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

主に確認できるのは以下です。

PHP-FPMの起動
PHP-FPMの停止
設定ファイルの読み込みエラー
poolの異常
worker processの異常終了
pm.max_children 到達
ソケットのbindエラー
PHP-FPMの初期化失敗

起動・停止ログ

PHP-FPMが正常に起動すると、以下のようなログが出ます。

NOTICE: fpm is running
NOTICE: ready to handle connections

停止時には、以下のようなログが出ます。

NOTICE: Terminating ...
NOTICE: exiting, bye-bye!

このようなログは、PHP-FPMが正常に起動・停止しているかを確認するために使います。

設定エラー

PHP-FPMの設定に問題がある場合、以下のようなエラーが出ることがあります。

ERROR: failed to open configuration file
ERROR: unable to bind listening socket
ERROR: FPM initialization failed

この場合は、PHP-FPMの設定ファイル、listen設定、ソケットパス、ポート競合、権限などを確認します。

PHP error log

PHP error logは、PHPアプリケーション実行時のエラーを記録するログです。

PHP-FPM error logとは役割が異なります。

PHP-FPM error logはPHP-FPM本体のログであり、PHP error logはPHPコード側のエラーを確認するためのログです。

PHP error logに出る主な内容

PHP error logには、以下のようなエラーが出ます。

PHP Fatal error:  Uncaught Error: Call to undefined function ...
PHP Warning:  Undefined array key "name" in /var/www/html/index.php on line 12
PHP Parse error:  syntax error, unexpected token ...

主に確認できるのは以下です。

Fatal error
Warning
Notice
Deprecated
Parse error
メモリ上限エラー
クラスや関数の未定義エラー
権限エラー
フレームワークやCMSの例外

PHPのバージョンによって、同じ問題でもNoticeではなくWarningとして出ることがあります。

そのため、ログの文言はPHPのバージョンによって多少変わる点に注意が必要です。

PHP error logの設定例

PHPアプリケーションのエラーをログに出すには、以下のような設定を行います。

php_admin_flag[log_errors] = on
php_admin_flag[display_errors] = off
php_admin_value[error_log] = /var/log/php-fpm/www-php-error.log

本番環境では、display_errors は基本的にoffにします。

php_admin_flag[display_errors] = off

display_errors がonになっていると、エラー内容がブラウザ上に表示され、ファイルパスや内部構造が外部に漏れる可能性があります。

一方で、エラーをログに残すために log_errors はonにします。

php_admin_flag[log_errors] = on

PHP-FPM slowlog

PHP-FPM slowlogは、一定時間以上かかったPHPリクエストを記録するログです。

PHP-FPMログの中でも、パフォーマンス調査に非常に役立ちます。

slowlogで分かること

slowlogを有効にすると、処理に時間がかかったPHPリクエストについて、どのPHPファイルのどの関数で止まっていたのかを確認できます。

たとえば、以下のような情報が記録されます。

[05-Jul-2026 12:40:01]  [pool www] pid 2345
script_filename = /var/www/html/index.php
[0x00007f...] mysqli_query() /var/www/html/app/Repository/PostRepository.php:58
[0x00007f...] getPosts() /var/www/html/app/Controller/PostController.php:22
[0x00007f...] index() /var/www/html/public/index.php:10

この例では、mysqli_query() で時間がかかっているため、DBクエリが遅い可能性があります。

slowlogを見ることで、以下のような原因を推測できます。

DBクエリが遅い
外部APIの応答待ちが発生している
ファイルI/Oで詰まっている
特定のPHP関数で処理が止まっている
WordPressの特定プラグインが重い
Laravelの特定処理が遅い
管理画面やAjax処理だけが遅い

slowlogの設定例

slowlogを有効にするには、pool設定に以下を記述します。

slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5s

request_slowlog_timeout は、何秒以上かかったリクエストをslowlogに記録するかを指定する設定です。

たとえば以下の場合、5秒以上かかったPHPリクエストがslowlogに記録されます。

request_slowlog_timeout = 5s

注意点として、request_slowlog_timeout のデフォルトは 0 です。

0 はoffを意味するため、slowlog のパスだけを設定しても、request_slowlog_timeout が 0 のままだとslowlogは実質的に動きません。

そのため、slowlogは以下の2つをセットで設定します。

slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5s

PHP-FPM access log

PHP-FPM access logは、PHP-FPMが処理したリクエスト単位の情報を記録するログです。

Nginxのアクセスログとは別に、PHP-FPM側で処理したPHPリクエストの情報を確認できます。

PHP-FPM access logで分かること

PHP-FPM access logでは、設定次第で以下のような情報を記録できます。

リモートIP
HTTPメソッド
リクエストURI
HTTPステータス
実行されたPHPファイル
処理時間
メモリ使用量
CPU使用率
pool名
worker processのPID

Nginxのアクセスログと組み合わせることで、どのリクエストがPHP側で重かったのかを調査しやすくなります。

ただし、PHP-FPM access logはデフォルトで必ず有効になっているわけではありません。

pool設定で access.log を明示的に指定することで有効になります。

PHP-FPM access logの設定例

PHP-FPM access logを有効にするには、以下のように設定します。

access.log = /var/log/php-fpm/www-access.log
access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{milliseconds}d %{kilo}M %C%%"

この設定では、以下のようなログを出力できます。

127.0.0.1 - - [05/Jul/2026:12:45:00 +0900] "GET /index.php?id=1" 200 /var/www/html/index.php 123 2048 12.30%

access.formatの主な指定子

PHP-FPM access logでは、access.format によってログの出力内容をカスタマイズできます。

主な指定子は以下です。

指定子	意味
`%R`	リモートIP
`%u`	Basic認証ユーザー
`%t`	リクエストを受け取った時刻
`%T`	ログを書いた時刻、つまりリクエスト完了時刻
`%m`	HTTPメソッド
`%r`	クエリ文字列を除いたRequest URI
`%q`	クエリ文字列
`%Q`	クエリ文字列がある場合の `?`
`%s`	レスポンスステータス
`%f`	実行されたPHPファイル
`%d`	処理時間
`%{milliseconds}d`	処理時間、ミリ秒
`%{microseconds}d`	処理時間、マイクロ秒
`%M`	PHPが割り当てたピークメモリ
`%{kilo}M`	ピークメモリ、KB
`%{mega}M`	ピークメモリ、MB
`%C`	CPU使用率
`%n`	pool名
`%p`	リクエストを処理した子プロセスPID
`%P`	親プロセスPID

注意点として、%r はクエリ文字列を含まないRequest URIです。

クエリ文字列まで記録したい場合は、以下のように %r%Q%q を使います。

access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{milliseconds}d %{kilo}M %C%%"

PHP-FPMログの主な出力先

PHP-FPMログの出力先は、OS、PHPバージョン、インストール方法、Docker利用有無によって異なります。

Ubuntu / Debian系でよくあるログパス

UbuntuやDebian系では、以下のようなパスがよく使われます。

/var/log/php8.2-fpm.log
/var/log/php8.3-fpm.log
/var/log/php8.4-fpm.log

pool別にログを分けている場合は、以下のようなパスもあります。

/var/log/php-fpm/www-error.log
/var/log/php-fpm/www-slow.log
/var/log/php-fpm/www-access.log
/var/log/php-fpm/www-php-error.log

ただし、これらはあくまで代表例です。

PHPのインストール元やサーバー構成によって、ログパスは変わります。

CentOS / RHEL / AlmaLinux / Rocky Linux系でよくあるログパス

Red Hat系のディストリビューションでは、以下のようなパスがよく使われます。

/var/log/php-fpm/error.log
/var/log/php-fpm/www-error.log
/var/log/php-fpm/www-slow.log

pool設定ファイルは、以下に置かれることが多いです。

/etc/php-fpm.d/www.conf

Docker環境でのログ確認

Docker環境では、ログファイルではなく標準出力・標準エラーに流す構成がよく使われます。

この場合、ログは以下で確認します。

docker logs -f コンテナ名

Docker Composeを使っている場合は、以下です。

docker compose logs -f php

Dockerでは、PHP-FPMのログを /proc/self/fd/2 に流す設定がよく使われます。

error_log = /proc/self/fd/2
access.log = /proc/self/fd/2
php_admin_value[error_log] = /proc/self/fd/2

systemd環境でのログ確認

PHP-FPMがsystemdで管理されている場合は、journalctl でログを確認できます。

journalctl -u php8.3-fpm

直近1時間のログを見る場合は、以下です。

journalctl -u php8.3-fpm --since "1 hour ago"

リアルタイムで追う場合は、以下です。

journalctl -u php8.3-fpm -f

サービス名が分からない場合は、以下で確認できます。

systemctl list-units | grep fpm

PHP-FPMの設定ファイル

PHP-FPMの設定ファイルは、大きく分けて2種類あります。

グローバル設定

PHP-FPM全体に関わる設定です。

Ubuntu / Debian系では、以下のようなパスにあります。

/etc/php/8.3/fpm/php-fpm.conf

Red Hat系では、以下のようなパスが使われます。

/etc/php-fpm.conf

グローバル設定では、主に以下のような項目を設定します。

error_log = /var/log/php8.3-fpm.log
log_level = notice

Dockerでは、以下のように標準エラーへ流すこともあります。

error_log = /proc/self/fd/2
log_level = notice

pool設定

pool設定は、PHP-FPMのworker processやアプリケーション単位の設定を管理するファイルです。

Ubuntu / Debian系では、以下のようなパスが使われます。

/etc/php/8.3/fpm/pool.d/www.conf

Red Hat系では、以下のようなパスが使われます。

/etc/php-fpm.d/www.conf

pool設定では、主に以下のような項目を設定します。

user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock

access.log = /var/log/php-fpm/www-access.log
slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5s

php_admin_flag[log_errors] = on
php_admin_flag[display_errors] = off
php_admin_value[error_log] = /var/log/php-fpm/www-php-error.log
catch_workers_output = yes

PHP-FPMログ関連の主な設定

PHP-FPMログを理解するうえで重要な設定を整理します。

error_log

error_log は、PHP-FPM本体のエラーログ出力先です。

error_log = /var/log/php8.3-fpm.log

Dockerでは、標準エラーに流すために以下のようにすることがあります。

error_log = /proc/self/fd/2

error_log はPHP-FPMのグローバル設定として扱います。

log_level

log_level は、PHP-FPMログの詳細度を指定する設定です。

log_level = notice

主に以下の値を使います。

alert
error
warning
notice
debug

通常運用では、notice または warning が使われることが多いです。

トラブル調査時に一時的に debug にすることもありますが、ログ量が増えるため、本番環境で長時間使うのは避けた方が安全です。

catch_workers_output

catch_workers_output は、worker processの標準出力・標準エラーをPHP-FPMのメインエラーログへ流す設定です。

catch_workers_output = yes

未設定の場合、workerのstdout/stderrは捨てられることがあります。

ただし、catch_workers_output はPHPエラーの正式な出力先を決める設定ではありません。

PHPアプリケーションのエラーをログに出すには、以下のような設定も必要です。

php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php-fpm/www-php-error.log

整理すると、以下のようになります。

設定	役割
`catch_workers_output = yes`	workerのstdout/stderrをFPMログへ流す
`php_admin_flag[log_errors] = on`	PHPエラーをログに出す
`php_admin_value[error_log] = ...`	PHPエラーの出力先を指定する

php_admin_value[error_log]

php_admin_value[error_log] は、PHPアプリケーションのエラーログ出力先を指定する設定です。

php_admin_value[error_log] = /var/log/php-fpm/www-php-error.log

php_admin_value で指定した値は、アプリケーション側の ini_set() では上書きできません。

php_admin_flag[log_errors]

php_admin_flag[log_errors] は、PHPエラーをログに出すかどうかを指定する設定です。

php_admin_flag[log_errors] = on

本番環境では、基本的にonにします。

php_admin_flag[display_errors]

php_admin_flag[display_errors] は、PHPエラーをブラウザ上に表示するかどうかを指定する設定です。

php_admin_flag[display_errors] = off

本番環境では、基本的にoffにします。

エラーを画面に表示すると、サーバー上のファイルパス、クラス名、内部構造などが外部に見えてしまう可能性があります。

slowlog

slowlog は、遅いリクエストのログ出力先です。

slowlog = /var/log/php-fpm/www-slow.log

request_slowlog_timeout と組み合わせて使用します。

request_slowlog_timeout

request_slowlog_timeout は、何秒以上かかったリクエストをslowlogに記録するかを指定します。

request_slowlog_timeout = 5s

調査時は、まず 5s や 3s から始めることが多いです。

細かく調査したい場合は 1s にすることもありますが、ログ量が増える点に注意が必要です。

access.log

access.log は、PHP-FPM access logの出力先です。

access.log = /var/log/php-fpm/www-access.log

デフォルトでは必ず有効になっているわけではないため、必要に応じて明示的に設定します。

access.format

access.format は、PHP-FPM access logの出力形式を指定する設定です。

access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{milliseconds}d %{kilo}M %C%%"

処理時間、メモリ使用量、CPU使用率などを出せるため、PHP側のパフォーマンス調査に役立ちます。

よくあるPHP-FPMログと原因

PHP-FPMのログには、実務でよく見る典型的なメッセージがあります。

ここでは、代表的なログと原因を解説します。

server reached pm.max_children setting

以下のようなログが出ることがあります。

WARNING: [pool www] server reached pm.max_children setting (10), consider raising it

これは、PHP-FPMの子プロセス数が上限に達したという意味です。

つまり、PHPリクエストを処理するworkerがすべて埋まっており、新しいリクエストをすぐに処理できない状態です。

このログが頻繁に出る場合、以下のような症状が起きやすくなります。

サイトが重い
たまに502 Bad Gatewayになる
たまに504 Gateway Timeoutになる
Nginx側でupstream timed outが出る
PHP-FPMの待ち行列が増える
アクセスが多い時間帯だけ遅くなる

主な原因は以下です。

pm.max_children が少なすぎる
PHP処理が遅い
DBクエリが遅い
外部API待ちが多い
WordPressプラグインが重い
キャッシュが効いていない
botやクローラーのアクセスが多い
worker 1プロセスあたりのメモリ使用量が大きい

単純に pm.max_children を上げればよいとは限りません。

pm.max_children を上げすぎると、今度はメモリ不足でサーバー全体が不安定になる可能性があります。

pm.max_childrenの考え方

pm.max_children は、PHP-FPMに割り当て可能なメモリと、1プロセスあたりのメモリ使用量を見て決めます。

目安は以下です。

pm.max_children ≒ PHP-FPMに割り当て可能なメモリ ÷ 1プロセスあたりの高めの実測メモリ

たとえば、PHP-FPMに使えるメモリが1GBで、PHP-FPMの1プロセスが高めに見て80MB使う場合、以下のようになります。

1024MB ÷ 80MB = 約12

この場合、pm.max_children は12前後が目安になります。

ただし、同じサーバー上でNginx、MySQL、Redis、cron、監視エージェントなどが動いている場合、それらのメモリも残す必要があります。

現在の設定は以下で確認できます。

grep -E "pm\.max_children|pm\.start_servers|pm\.min_spare_servers|pm\.max_spare_servers" /etc/php/*/fpm/pool.d/www.conf

PHP-FPMプロセスのメモリ使用量は、以下で確認できます。

ps -ylC php-fpm --sort:rss

環境によっては、以下の方が確認しやすい場合もあります。

ps aux | grep php-fpm

child exited on signal 9

以下のようなログが出ることがあります。

WARNING: [pool www] child 12345 exited on signal 9 (SIGKILL)

これは、PHP-FPMの子プロセスが SIGKILL によって強制終了されたことを意味します。

原因として多いのはメモリ不足によるOOM Killerですが、OOM確定ではありません。

主な原因は以下です。

Linux OOM Killerによる強制終了
systemdやコンテナランタイムによるkill
管理者が kill -9 した
デプロイスクリプトや監視ツールがkillした
DockerやKubernetesのメモリ制限に到達した
ホスティング環境側の制御

OOMが疑われる場合は、以下を確認します。

dmesg -T | grep -i -E "killed process|out of memory|oom"

systemd journalでも確認できます。

journalctl -k | grep -i -E "killed process|out of memory|oom"

Docker環境では、コンテナのメモリ制限も確認します。

docker inspect コンテナ名 | grep -i oom

対応としては、以下が考えられます。

pm.max_children を下げる
PHPコードのメモリ使用量を減らす
重い処理をキュー化する
画像処理やCSV処理をWebリクエストから切り離す
サーバーメモリを増やす
DBやRedisを別サーバーに分離する

child exited on signal 11

以下のようなログが出ることがあります。

WARNING: [pool www] child 12345 exited on signal 11 (SIGSEGV)

これは、PHP-FPMの子プロセスがセグメンテーションフォルトで落ちたことを意味します。

PHPコードの通常のFatal errorというより、PHP本体やC拡張、ネイティブライブラリ周辺の問題で発生することが多いです。

主な原因は以下です。

PHP本体のバグ
PHP拡張のバグ
PHPバージョンと拡張の互換性問題
OPcacheやJIT関連
Imagickなど画像処理系拡張
ionCube Loader
Xdebug
OSライブラリ更新後の不整合
ネイティブライブラリの問題
まれにメモリやハードウェアの異常

まずは、PHP拡張一覧を確認します。

php -m

最近追加・更新した拡張があれば、それを疑います。

OPcacheやJITが関係していそうな場合は、検証環境で一時的に無効化して再現性を確認することもあります。

opcache.enable=0

ただし、本番環境でOPcacheを無効にするとパフォーマンスが大きく落ちるため、検証環境で確認するのが安全です。

Primary script unknown

以下のようなログが出ることがあります。

Primary script unknown

これは、PHP-FPMが実行すべきPHPファイルを見つけられない場合に出ることがあります。

NginxとPHP-FPMの設定不整合でよく発生します。

主な原因は以下です。

Nginxの SCRIPT_FILENAME が間違っている
root や alias の設定が合っていない
PHPファイルが存在しない
DockerでNginxコンテナとPHP-FPMコンテナのマウントパスが違う
fastcgi_param SCRIPT_FILENAME の指定ミス
security.limit_extensions に引っかかっている

一般的なNginx設定例は以下です。

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

alias を使っている場合は、$document_root$fastcgi_script_name ではなく、以下の方が適切なケースがあります。

fastcgi_param SCRIPT_FILENAME $request_filename;

Docker環境では、NginxコンテナとPHP-FPMコンテナのパスが一致しているかを確認することが重要です。

Nginx側に出るPHP-FPM関連エラー

PHP-FPMの問題は、Nginx側のエラーログに現れることもあります。

connect() to unix socket failed

Nginx側で以下のようなログが出ることがあります。

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

これは、NginxがPHP-FPMのUnixソケットに接続できない状態です。

主な原因は以下です。

PHP-FPMが起動していない
ソケットのパスが違う
PHPバージョン変更後にNginx設定が古い
ソケットファイルの権限が合っていない
PHP-FPMの listen とNginxの fastcgi_pass が一致していない

確認コマンドは以下です。

grep "^listen" /etc/php/*/fpm/pool.d/www.conf

Nginx側の fastcgi_pass も確認します。

grep -R "fastcgi_pass" /etc/nginx/sites-enabled /etc/nginx/conf.d

PHP-FPMが起動しているか確認します。

systemctl status php8.3-fpm

ソケットが存在するか確認します。

ls -l /run/php/

PHP-FPMログを見るための基本コマンド

PHP-FPMログを調査するときによく使うコマンドを整理します。

リアルタイムでログを見る

tail -f /var/log/php8.3-fpm.log

Nginxログと一緒に見る場合は、以下のようにします。

tail -f /var/log/nginx/error.log /var/log/php8.3-fpm.log

エラーや警告だけ抽出する

grep -i "error\|warning\|fatal" /var/log/php8.3-fpm.log

max_children関連を見る

grep -i "max_children" /var/log/php8.3-fpm.log

OOM関連を見る

dmesg -T | grep -i -E "killed process|out of memory|oom"

systemdログを見る

journalctl -u php8.3-fpm --since "1 hour ago"

リアルタイムで見る場合は、以下です。

journalctl -u php8.3-fpm -f

PHP-FPM設定をテストする

設定変更後は、構文チェックを行います。

php-fpm8.3 -t

環境によっては、以下の場合もあります。

php-fpm -t

問題なければ、PHP-FPMをリロードします。

systemctl reload php8.3-fpm

必要に応じて再起動します。

systemctl restart php8.3-fpm

通常は、可能であれば restart より reload の方が影響が小さくなります。

502 Bad Gateway発生時の確認手順

502 Bad Gatewayが発生した場合は、NginxがPHP-FPMとうまく通信できていない可能性があります。

まずNginxのエラーログを見る

tail -n 100 /var/log/nginx/error.log

以下のようなログがないか確認します。

connect() failed
upstream prematurely closed connection
recv() failed while reading response header from upstream
no live upstreams

PHP-FPMが起動しているか確認する

systemctl status php8.3-fpm

起動していない場合は、設定エラーやソケットエラーを確認します。

journalctl -u php8.3-fpm --since "30 minutes ago"

PHP-FPM error logを見る

tail -n 100 /var/log/php8.3-fpm.log

以下のようなログがないか確認します。

server reached pm.max_children setting
child exited on signal 9
child exited on signal 11
FPM initialization failed

ソケット設定を確認する

PHP-FPM側のlisten設定を確認します。

grep "^listen" /etc/php/*/fpm/pool.d/www.conf

Nginx側の fastcgi_pass を確認します。

grep -R "fastcgi_pass" /etc/nginx/sites-enabled /etc/nginx/conf.d

PHP-FPM側とNginx側で、ソケットパスまたはTCPポートが一致している必要があります。

504 Gateway Timeout発生時の確認手順

504 Gateway Timeoutは、PHP-FPMからの応答が遅すぎる場合に発生することがあります。

Nginxのエラーログを見る

tail -n 100 /var/log/nginx/error.log

以下のようなログが出ていないか確認します。

upstream timed out

PHP-FPM slowlogを見る

tail -n 100 /var/log/php-fpm/www-slow.log

slowlogに同じファイルや同じ関数が頻繁に出ている場合、その処理がボトルネックになっている可能性があります。

PHP-FPM workerの詰まりを確認する

grep -i "max_children" /var/log/php8.3-fpm.log

pm.max_children に頻繁に到達している場合、PHP-FPMのworkerが詰まっている可能性があります。

リソースを確認する

top
free -m
df -h

CPU、メモリ、ディスク容量を確認します。

DBが同じサーバーにある場合は、DB側の負荷も確認します。

WordPressでPHP-FPMログを見るポイント

WordPressサイトでは、PHP-FPMログが非常に重要です。

WordPressでよく見る問題

WordPressでは、以下のような問題がPHP-FPMログに現れやすいです。

pm.max_children 到達
admin-ajax.php が重い
wp-cron.php が重い
xmlrpc.php へのアクセスが多い
プラグイン起因のFatal error
テーマの functions.php のエラー
WooCommerceの重いクエリ
REST APIリクエストが多い
botアクセスでPHP-FPMが詰まる

slowlogで注意したいパス

WordPressでは、slowlogに以下のようなパスが頻出する場合があります。

/wp-admin/admin-ajax.php
/wp-cron.php
/wp-json/
/xmlrpc.php

これらが頻繁に出る場合は、以下を確認します。

ページキャッシュが効いているか
オブジェクトキャッシュがあるか
不要なプラグインがないか
admin-ajax.php を多用するプラグインがないか
wp-cron.php が過剰に実行されていないか
botや不正アクセスが多くないか
WooCommerceのクエリが重くないか

WordPressでの主な対策

WordPressでPHP-FPMが詰まりやすい場合は、以下のような対策が考えられます。

ページキャッシュを導入する
オブジェクトキャッシュを導入する
wp-cron.php をサーバーcronに移す
不要なプラグインを削除する
重いプラグインを見直す
WooCommerceのDBクエリを確認する
xmlrpc.php を不要なら制限する
CDNやWAFでbotアクセスを制限する

LaravelでPHP-FPMログを見るポイント

Laravelでは、PHP-FPMログだけでなくLaravel側のログも確認します。

Laravel側のログ

Laravelのログは、通常以下にあります。

storage/logs/laravel.log

PHP-FPM側にFatal errorや権限エラーが出ている場合でも、詳細はLaravelログに残っていることがあります。

LaravelでよくあるPHP-FPM関連エラー

Laravelでは、以下のような問題がよくあります。

storage ディレクトリに書き込めない
bootstrap/cache に書き込めない
.env の設定ミス
Composer依存関係の問題
キャッシュファイルの不整合
Fatal error
メモリ不足
slowlogにDB待ちが出る

たとえば、以下のようなエラーが出ることがあります。

PHP Fatal error:  Uncaught UnexpectedValueException: The stream or file "/var/www/html/storage/logs/laravel.log" could not be opened in append mode: Permission denied

この場合、PHP-FPMの実行ユーザーが storage/logs に書き込めていません。

PHP-FPMの実行ユーザーを確認します。

ps aux | grep php-fpm

www-data で動いている場合は、以下のように権限を調整します。

sudo chown -R www-data:www-data storage bootstrap/cache

ただし、実際のユーザー名は環境によって異なります。

www-data、nginx、apache など、実際の実行ユーザーに合わせて設定してください。

ログが出ない場合の確認ポイント

PHP-FPMログを設定したのにログが出ない場合は、以下を確認します。

ログパスが正しいか確認する

設定ファイル内のログ関連設定を検索します。

grep -R "error_log\|slowlog\|request_slowlog_timeout\|access.log\|catch_workers_output" /etc/php /etc/php-fpm* 2>/dev/null

ログディレクトリの権限を確認する

ls -ld /var/log/php-fpm
ls -l /var/log/php-fpm/

PHP-FPMの実行ユーザーも確認します。

ps aux | grep php-fpm

ログファイルによって、master processが書く場合とworker processが書く場合があります。

そのため、ログディレクトリ全体を一律で www-data:www-data にするのではなく、対象ログごとに書き込みユーザーを確認して権限を調整するのが安全です。

request_slowlog_timeoutが0になっていないか確認する

slowlogが出ない場合は、以下を確認します。

request_slowlog_timeout = 5s

request_slowlog_timeout = 0 のままだと、slowlogは出ません。

access.logが設定されているか確認する

PHP-FPM access logは、access.log を設定しないと出ません。

access.log = /var/log/php-fpm/www-access.log

PHP-FPMをリロードしているか確認する

設定を変更した後は、構文チェックとリロードを行います。

php-fpm8.3 -t
systemctl reload php8.3-fpm

logrotateの設定

PHP-FPMログを有効にすると、ログファイルが増え続けます。

そのため、logrotateの設定も重要です。

logrotate設定の例

以下は一例です。

/var/log/php-fpm/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    sharedscripts
    postrotate
        systemctl reload php8.3-fpm > /dev/null 2>&1 || true
    endscript
}

create を指定する場合は、実際の環境に合わせて所有者とグループを指定します。

たとえば、環境によって以下のように変わります。

create 0640 root adm
create 0640 www-data adm
create 0640 nginx nginx
create 0640 apache apache

PHP-FPMの実行ユーザーやログを書き込むユーザーに合わせて設定してください。

ログローテーションが適切に設定されていないと、ログファイルが肥大化し、ディスク容量不足を引き起こす可能性があります。

ディスク容量不足になると、PHP-FPMだけでなくNginx、MySQL、Redisなどにも影響するため注意が必要です。

本番環境でおすすめのPHP-FPMログ設定

本番環境では、基本的に以下の方針がおすすめです。

PHP-FPM本体ログ

グローバル設定側で、PHP-FPM本体ログを設定します。

error_log = /var/log/php8.3-fpm.log
log_level = notice

Docker環境では、標準エラーへ流す構成もよく使われます。

error_log = /proc/self/fd/2
log_level = notice

PHPアプリケーションエラーログ

pool設定側で、PHPアプリケーションのエラーログを設定します。

php_admin_flag[log_errors] = on
php_admin_flag[display_errors] = off
php_admin_value[error_log] = /var/log/php-fpm/www-php-error.log

本番環境では、エラーを画面に表示せず、ログに記録するのが基本です。

slowlog

パフォーマンス調査のために、slowlogも有効化しておくと便利です。

slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5s

負荷状況に応じて、3s や 1s に調整することもあります。

ただし、短くしすぎるとログ量が増えるため注意が必要です。

PHP-FPM access log

FPM access logは便利ですが、アクセス数が多いサイトではログ量が多くなります。

小〜中規模サイトでは常時有効でも問題ないことが多いですが、大規模サイトでは調査時だけ有効にする、またはログ基盤へ送る設計にする方が安全です。

設定例は以下です。

access.log = /var/log/php-fpm/www-access.log
access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{milliseconds}d %{kilo}M %C%%"

PHP-FPMログ調査の実践フロー

PHP-FPM関連の障害が起きた場合は、いきなり設定を変更するのではなく、順番にログを確認することが重要です。

まずNginxログを見る

tail -n 100 /var/log/nginx/error.log

502、504、upstream関連のエラーがないか確認します。

PHP-FPMの状態を確認する

systemctl status php8.3-fpm

起動失敗やクラッシュがないか確認します。

PHP-FPM本体ログを見る

tail -n 100 /var/log/php8.3-fpm.log

または、systemd環境では以下を確認します。

journalctl -u php8.3-fpm --since "1 hour ago"

PHPエラーログを見る

tail -n 100 /var/log/php-fpm/www-php-error.log

PHPのFatal error、Warning、Parse errorなどがないか確認します。

slowlogを見る

tail -n 100 /var/log/php-fpm/www-slow.log

重いPHP処理がないか確認します。

max_children到達を確認する

grep -i "max_children" /var/log/php8.3-fpm.log

pm.max_children に頻繁に到達している場合、workerが足りていないか、PHP処理が遅すぎる可能性があります。

OOMを確認する

dmesg -T | grep -i -E "killed process|out of memory|oom"

PHP-FPMの子プロセスがメモリ不足でkillされていないか確認します。

サーバーリソースを確認する

top
free -m
df -h

CPU、メモリ、ディスク容量を確認します。

PHP-FPMログのまとめ

PHP-FPMログは、PHPアプリケーションの運用や障害対応において非常に重要です。

Nginxのログだけでは、PHP内部のエラーや処理遅延までは把握できません。

PHP-FPMログを見ることで、以下のような問題を切り分けやすくなります。

PHP-FPMが起動しているか
PHP-FPMが正常にリクエストを処理しているか
PHPアプリケーションでFatal errorが出ていないか
PHP処理がどこで遅くなっているか
pm.max_children に到達していないか
worker processがクラッシュしていないか
メモリ不足でkillされていないか
NginxとPHP-FPMの接続設定が合っているか

特に重要なログは以下です。

PHP-FPM error log
PHP error log
PHP-FPM slowlog

PHP-FPM access logも、処理時間やメモリ使用量を確認できるため、パフォーマンス調査では有効です。

実務では、以下の順で確認すると効率的です。

tail -n 100 /var/log/nginx/error.log
journalctl -u php8.3-fpm --since "1 hour ago"
tail -n 100 /var/log/php8.3-fpm.log
tail -n 100 /var/log/php-fpm/www-php-error.log
tail -n 100 /var/log/php-fpm/www-slow.log
grep -i "max_children" /var/log/php8.3-fpm.log
dmesg -T | grep -i -E "killed process|out of memory|oom"

PHP-FPMログを正しく読めるようになると、Webサーバー側の問題なのか、PHPアプリケーション側の問題なのか、DBや外部APIが原因なのかをかなり正確に切り分けられます。

そのため、PHP-FPMを使う環境では、ログの種類、設定場所、確認コマンド、典型的なエラーメッセージを理解しておくことが重要です。

以上、PHP-FPMのログについてでした。

最後までお読みいただき、ありがとうございました。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

PHP-FPMのログについて

採用はこちら

PHP-FPMの基本的な役割

PHP-FPMで確認すべき主なログ

PHP-FPM error log

PHP-FPM error logに出る主な内容

起動・停止ログ

設定エラー

PHP error log

PHP error logに出る主な内容

PHP error logの設定例

PHP-FPM slowlog

slowlogで分かること

slowlogの設定例

PHP-FPM access log

PHP-FPM access logで分かること

PHP-FPM access logの設定例

access.formatの主な指定子

PHP-FPMログの主な出力先

Ubuntu / Debian系でよくあるログパス

CentOS / RHEL / AlmaLinux / Rocky Linux系でよくあるログパス

Docker環境でのログ確認

systemd環境でのログ確認

PHP-FPMの設定ファイル

グローバル設定

pool設定

PHP-FPMログ関連の主な設定

error_log

log_level

catch_workers_output

php_admin_value[error_log]

php_admin_flag[log_errors]

php_admin_flag[display_errors]

slowlog

request_slowlog_timeout

access.log

access.format

よくあるPHP-FPMログと原因

server reached pm.max_children setting

pm.max_childrenの考え方

child exited on signal 9

child exited on signal 11

Primary script unknown

Nginx側に出るPHP-FPM関連エラー

connect() to unix socket failed

PHP-FPMログを見るための基本コマンド

リアルタイムでログを見る

エラーや警告だけ抽出する

max_children関連を見る

OOM関連を見る

systemdログを見る

PHP-FPM設定をテストする

502 Bad Gateway発生時の確認手順

まずNginxのエラーログを見る

PHP-FPMが起動しているか確認する

PHP-FPM error logを見る

ソケット設定を確認する

504 Gateway Timeout発生時の確認手順

Nginxのエラーログを見る

PHP-FPM slowlogを見る

PHP-FPM workerの詰まりを確認する

リソースを確認する

WordPressでPHP-FPMログを見るポイント

WordPressでよく見る問題

slowlogで注意したいパス

WordPressでの主な対策

LaravelでPHP-FPMログを見るポイント

Laravel側のログ

LaravelでよくあるPHP-FPM関連エラー

ログが出ない場合の確認ポイント

ログパスが正しいか確認する

ログディレクトリの権限を確認する

request_slowlog_timeoutが0になっていないか確認する

access.logが設定されているか確認する

PHP-FPMをリロードしているか確認する

logrotateの設定

logrotate設定の例

本番環境でおすすめのPHP-FPMログ設定

PHP-FPM本体ログ

PHPアプリケーションエラーログ