2026年6月26日

2026年6月26日

PHP-FPMのインストールと設定方法:WordPress向けのプール設定とNginx・Apache連携

PHP-FPM は、Web サーバーから受け取ったリクエストを PHP のワーカープロセスで処理する仕組みで、Nginx で WordPress を動かす場合の標準的な構成です。この記事では、Ubuntu を中心にインストールからプール設定(www.conf)、pm.max_children の決め方、Nginx・Apache との接続、動作確認とよくあるエラーの対処までを説明します。

PHP-FPMの役割

Nginx は PHP を自分では実行できないため、PHP の処理を FastCGI という方式で PHP-FPM に渡します。PHP-FPM はあらかじめ起動しておいたワーカープロセスにリクエストを処理させます。Apache でも mod_php の代わりに PHP-FPM を使うと、サイトごとに実行ユーザーを分けるといった構成が取りやすくなります。

設定の単位は プール です。プールごとにソケット、実行ユーザー、ワーカー数、PHP の設定値を決められます。

インストール

作業前に、サーバーのスナップショットや設定ファイルのバックアップを取っておきます。本番で動いているサーバーの場合は、ステージング環境で同じ手順を試してから適用してください。

Ubuntu・Debianの場合

ディストリビューション標準のリポジトリに含まれる PHP をインストールする例です。Ubuntu 24.04 では PHP 8.3、Debian 12 では PHP 8.2 が標準です(2026年10月現在。OS のバージョンによって異なります)。以下は PHP 8.3 の例なので、手元のバージョンに読み替えてください。

sudo apt update
sudo apt install php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd php8.3-mbstring \
  php8.3-xml php8.3-zip php8.3-intl php-imagick

php8.3-fpm 以外は WordPress でよく使われる拡張モジュールです(画像処理の Imagick はバージョン番号の付かないパッケージ名で提供されている場合があります。apt search imagick で名前を確認してください)。php8.3-mysql がないとデータベースに接続できず、php8.3-mbstring がないと日本語の処理で問題が出ることがあります。標準リポジトリにないバージョンが必要な場合、外部のリポジトリ(PPA など)を使う方法もありますが、サポート期間や更新の提供元を確認したうえで判断してください。

インストール後、サービスが起動しているか確認します。

systemctl status php8.3-fpm
php-fpm8.3 -v

RHEL系(AlmaLinux・Rocky Linux)の場合

RHEL 系では dnf install php-fpm php-mysqlnd のようにパッケージ名にバージョンが付かず、PHP のバージョンはモジュールストリームなどで切り替えます。プールの設定は /etc/php-fpm.d/www.conf にあり、実行ユーザーの既定値も Ubuntu と異なるため、Nginx と組み合わせる場合は user・group とソケットの権限を確認してください。以降は Ubuntu のパスで説明します。

設定ファイルの場所

Ubuntu の PHP 8.3 では、主な設定ファイルは次の場所にあります。

  • /etc/php/8.3/fpm/php-fpm.conf: PHP-FPM 全体の設定(ログの場所など)
  • /etc/php/8.3/fpm/pool.d/www.conf: 既定のプール www の設定
  • /etc/php/8.3/fpm/php.ini: PHP-FPM で動く PHP の設定

コマンドラインの PHP は /etc/php/8.3/cli/php.ini を読むため、php -i で確認した値と Web 経由で動く PHP の値が違うことがあります。WordPress から見た値は、管理画面の「サイトヘルス」の情報画面で確認できます。

プール設定(www.conf)の主な項目

www.conf で特に重要な項目を抜き出した例です。既存の設定ファイルには説明のコメントが多く含まれているので、該当する行を探して書き換えます。

[www]
user = www-data
group = www-data

listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500

pm.status_path = /fpm-status
ping.path = /fpm-ping

request_slowlog_timeout = 5s
slowlog = /var/log/php8.3-fpm-slow.log
request_terminate_timeout = 120s

user・groupとlisten

user と group は PHP のワーカープロセスを動かすユーザーです。WordPress のファイルを書き込めるかどうか(プラグインの更新やメディアのアップロード)はこのユーザーの権限で決まります。

listen は Web サーバーからの接続を受ける場所です。同じサーバー内で接続するなら、TCP ポート(127.0.0.1:9000 など)より UNIX ソケットのほうが一般的です。ソケットを使う場合は、listen.owner・listen.group・listen.mode で Web サーバーのユーザーが読み書きできるようにします。ここが合っていないと、Nginx が接続できず 502 エラーになります。

pm(プロセス管理)

pm はワーカーの増減の方式です。

  • dynamic: pm.start_servers で起動し、待機中のワーカー数が pm.min_spare_servers と pm.max_spare_servers の範囲に収まるよう増減します。多くの環境で無難な選択です。
  • static: 常に pm.max_children の数だけ起動しておきます。メモリに余裕があり、アクセスが安定している専用サーバー向けです。
  • ondemand: リクエストが来たときだけワーカーを起動し、一定時間使われなければ終了します。メモリの少ない VPS や、アクセスの少ないサイトを多数載せるサーバーで使われます。

pm.max_requests は、ひとつのワーカーが指定回数のリクエストを処理したら入れ替える設定です。プラグインのメモリリークによってワーカーが少しずつ肥大化するのを抑えられます。

スローログとタイムアウト

request_slowlog_timeout を設定すると、指定時間を超えたリクエストのスタックトレースが slowlog に記録されます。どのプラグインのどの関数で時間がかかっているかを調べる手がかりになります。request_terminate_timeout は処理を強制終了するまでの時間で、PHP の max_execution_time とは別に働きます。インポート処理など長時間かかる作業がある場合は短くしすぎないよう注意します。

pm.max_childrenの決め方

pm.max_children は同時に処理できるリクエスト数の上限で、最も重要な値です。大きくしすぎるとメモリが足りなくなってスワップや OOM Killer によるプロセス停止が起き、小さすぎるとアクセスが集中したときに待ちが発生します。

目安は「PHP-FPM に割り当てられるメモリ ÷ ワーカー 1 つあたりの平均メモリ」です。実際に動いているワーカーの平均メモリ使用量は次のコマンドで確認できます。

ps --no-headers -o rss -C php-fpm8.3 | awk '{sum+=$1; n++} END {if (n) printf "%.1f MB (平均, %d プロセス)\n", sum/n/1024, n}'

WordPress では 1 ワーカーあたり数十 MB から 100 MB 超まで、プラグインの構成によって大きく変わります。たとえばメモリ 2 GB のサーバーで、OS・MySQL・Nginx に 1 GB 程度を残し、ワーカー 1 つが平均 80 MB なら、1024 ÷ 80 でおよそ 12 が上限の目安です。計算値をそのまま使うのではなく、少し低めに設定してから、アクセスが多い時間帯のメモリ使用量とログを見て調整します。

Webサーバーとの接続

Nginx

Ubuntu の Nginx パッケージには、PHP-FPM 用の設定をまとめた snippets/fastcgi-php.conf が含まれています。サーバーブロックに次のように書きます。

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

fastcgi_pass のソケットのパスは、www.conf の listen と一致している必要があります。PHP のバージョンを上げたときに、ここを古いバージョンのまま残してしまうのがよくある失敗です。

Apache

Apache では proxy_fcgi モジュールを使います。Ubuntu では PHP-FPM のパッケージに Apache 用の設定ファイルが付属しているので、次のコマンドで有効にできます。mod_php を使っていた場合は、無効にしてから切り替えます。

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.3-fpm
sudo apachectl configtest
sudo systemctl reload apache2

設定の反映と動作確認

設定を変更したら、反映前に構文を確認します。

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

reload は restart よりも処理中のリクエストへの影響を抑えて設定を反映できます。

pm.status_path を設定した場合は、Nginx に専用の location を追加すると、待機中・処理中のワーカー数や、上限に達した回数(max children reached)を確認できます。ステータスページはサーバー内部の情報を含むため、allow 127.0.0.1; deny all; のようにアクセスできる接続元を限定してください。

よくあるエラーと確認方法

  • 502 Bad Gateway: PHP-FPM が停止している、fastcgi_pass と listen のパスが一致していない、ソケットの権限が足りない、のいずれかが多い原因です。systemctl status php8.3-fpm と Nginx のエラーログ(/var/log/nginx/error.log)を確認します。
  • 「server reached pm.max_children setting」: PHP-FPM のログ(/var/log/php8.3-fpm.log)に出る警告で、ワーカーが足りずにリクエストが待たされた状態です。メモリに余裕があれば pm.max_children を上げ、なければスローログで重い処理を探してキャッシュの導入などを検討します。
  • 504 Gateway Timeout: PHP の処理が Nginx の fastcgi_read_timeout を超えています。スローログで原因の処理を特定するのが先で、タイムアウトを延ばすのは最後の手段です。
  • php.ini を変えても反映されない: cli 側の php.ini を編集している可能性があります。fpm 側を編集し、PHP-FPM を再読み込みします。

まとめ

  • PHP-FPM は Web サーバーから PHP の処理を受け取るプロセス管理の仕組みで、設定はプール単位で行う。
  • Ubuntu では /etc/php/バージョン/fpm/ 以下に設定があり、CLI 用の php.ini とは別に管理されている。
  • listen のソケットと Web サーバー側の fastcgi_pass を一致させ、ソケットの権限を合わせる。
  • pm.max_children は実測したワーカーのメモリ使用量から計算し、低めに設定してからログを見て調整する。
  • 変更前にバックアップを取り、php-fpm8.3 -t で構文を確認してから reload で反映する。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲