「セキュアにした次は、爆速化だ。」
WordOpsは、デフォルト状態でも十分に高速なWordPress環境を構築してくれます。しかし、そのデフォルト設定は、1コア/メモリ1GB〜2GBといった非力な格安VPSでも安全に動くように配慮された、いわば「デチューン（安全運転）状態」に過ぎません。
もしあなたが、自宅で眠っているマルチコアの物理サーバーや、スペックに余裕のあるミドル〜ハイスペックなVPSでWordOpsを運用しているなら、そのリソースのほとんどは宝の持ち腐れになっています。
今回は、WordPressの心臓部である「PHP-FPM」のリミッターを解除し、物理メモリを極限まで使い切って同時処理能力を爆発させるチューニング手順を解説します。
1. なぜデフォルトのWordOpsは「詰まる」のか？
WordOpsをインストールした直後の状態だと、アクセスが集中した時に「一瞬表示が重くなる」「502 Bad Gatewayが出る」といった現象に遭遇することがあります。
その原因の9割は、PHP-FPMの制御モードである pm = dynamic（動的プロセス生成）と、そのプロセス上限値の低さにあります。
デフォルトでは、同時に立ち上がるPHPのプロセス数（pm.max_children）が非常に小さく制限されています。これにより、数人が同時にページにアクセスしただけで、PHPの処理待ち行列（バックログ）が発生し、サーバーのCPUやメモリには余裕があるのに、WordPress側が勝手にボトルネックになって自滅してしまうのです。
2. 【理論編】物理メモリから導く「最大プロセス数」の黄金式
プロセス数をただ闇雲に増やすと、今度はメモリを食いつぶしてサーバーがクラッシュ（OOM Killerの起動）します。 そのため、あなたのサーバーの物理メモリ量に合わせて、適切な上限値（max_children）を計算して割り出す必要があります。 安全かつ極限まで攻めるための計算式は以下の通りです。
$$ \text{最大プロセス数 (max_children)} = \frac{\text{PHP-FPMに割り当てるメモリ容量} \ (\text{MB})}{\text{PHPプロセス1個あたりの平均消費メモリ} \ (\text{MB})} $$
💡 メモリ割り当ての計算（本環境：搭載メモリ48GBから将来のキャッシュ領域を引き、2サイトで折半する場合）
- システム全体： 48,000 MB（48GB）
- OS / Nginx / MySQL等の取り置き ＋ 将来のRedis ＋ RAMディスク化用プール： 約 20,000 MB（20GB）
- PHP-FPM全体枠（残り）： 28,000 MB（28GB）
- tech別館の割り当て（本館と半分ずつで折半）： 14,000 MB（14GB）
- PHPプロセス1個の平均消費： 約 50 MB（※プラグインが多めの重い環境を想定し、安全マージンを取り大きめに見積もります）
$$\text{max_children} = \frac{14000}{50} = 280 \ \text{プロセス}$$
この計算を元に、今回はプロセス上限値を 280 に決定しました。ご自身の環境に合わせて数値を割り出す際の参考にしてみてください。
3. なぜ初期設定の「ondemand」を捨てて「static」にするのか？
計算によって「tech別館は280プロセスまで並べられる」という目標値が決まりました。
しかし、WordOps（PHP 8.3環境）のデフォルトのプール個別設定ファイル（/etc/php/8.3/fpm/pool.d/www.conf）を開くと、実は以下のような設定になっています。
📄 WordOpsの初期設定コード（デフォルト）
[www-php83]
user = www-data
group = www-data
listen = php83-fpm.sock
listen.owner = root
listen.group = www-data
pm = ondemand
pm.max_children = 100
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 30
ping.path = /ping
pm.status_path = /status
pm.max_requests = 1500
request_terminate_timeout = 300
chdir = /
prefix = /var/run/php
listen.mode = 0660
listen.backlog = 32768
catch_workers_output = yes
php_admin_value[open_basedir] = "/var/www/:/usr/share/php/:/tmp/:/var/run/nginx-cache/:/dev/urandom:/dev/shm:/var/lib/php/sessions/"デフォルトはプロセスの制御モードが pm = ondemand になっており、最大プロセス数 pm.max_children も 100 に制限されています。 なぜ、この初期設定の「ondemand」を捨てて、わざわざ「static」に変更して280プロセス常時固定にする必要があるのでしょうか？ PHP-FPMの3つの動作モードの違いを、実際のサーバープロセス（psコマンド）の見え方と合わせて確認してみましょう。
🍳 PHP-FPMの3つの動作モード比較
① ondemand（オンデマンド：完全受注生産）※デフォルト設定
- 仕組み: アクセスが来た瞬間にプロセスを立ち上げ、処理が終わったら（一定時間アクセスがないと）即座にプロセスを消去します。
- サーバー上のプロセスの見え方: アクセスが全くない時間は、管理用の親プロセス（master）以外、実務を行う子プロセス（worker）がゼロになります。
# ps aux | grep php-fpm | grep -v grep
root 12345 0.0 0.1 12345 5678 ? Ss 04:00 0:00 php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf)
# (実務を行う worker プロセスが1つも存在しないため、空きメモリは最大になります)- メリット: メモリ消費がほぼゼロ。メモリ1GB〜2GB程度の格安VPSに最適。
- デメリット: 毎回「プロセスを作る ➡️ 処理する ➡️ 消す」という重いCPU処理（フォーク）が発生するため、ページの応答速度（TTFB）に必ず一瞬の遅延（スパイク）が出ます。
② dynamic（ダイナミック：動的調整）
- 仕組み: 基本数個のプロセスを常時待機させ、アクセス増に応じてプロセスを臨機応変に増やします。
- サーバー上のプロセスの見え方: アクセス状況に応じて、プロセスの数が数個〜数十個の間で常に増減（増殖と消滅）を繰り返します。
# ps aux | grep php-fpm | grep -v grep
root 12345 0.0 0.1 12345 5678 ? Ss 04:00 0:00 php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf)
www-data 12346 0.1 0.2 23456 7890 ? S 04:01 0:00 php-fpm: pool www-php83
www-data 12347 0.1 0.2 23456 7890 ? S 04:01 0:00 php-fpm: pool www-php83
www-data 12348 0.1 0.2 23456 7890 ? S 04:01 0:00 php-fpm: pool www-php83
# (アクセスの波に合わせて、下の子プロセスが3個から10個、20個へと忙しく増減する)- メリット: メモリと速度のバランスが良い、一般的なレンタルサーバーなどの推奨設定。
- デメリット: 急激なアクセス増（SNS砲など）で急遽プロセスを立ち上げる瞬間、CPUに高負荷がかかってサーバーが一瞬重くなります。
③ static（スタティック：静的常時固定）★今回採用！
- 仕組み: 指定した数のプロセス（今回は280個）を、アクセスがあろうがなかろうが、24時間365日メモリ上に立ち上げっぱなしにします。
- サーバー上のプロセスの見え方: サービスを起動した瞬間から、指定した上限（280プロセス）まで綺麗にワーカープロセスが限界突破して立ち並びます。
# ps aux | grep php-fpm | grep -v grep
root 12345 0.0 0.1 12345 5678 ? Ss 04:00 0:00 php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf)
www-data 12346 0.0 0.2 23456 7890 ? S 04:01 0:00 php-fpm: pool www-php83
www-data 12347 0.0 0.2 23456 7890 ? S 04:01 0:00 php-fpm: pool www-php83
... (中略) ...
www-data 12625 0.0 0.2 23456 7890 ? S 04:01 0:00 php-fpm: pool www-php83
# (常時、指定した280個 of ワーカープロセスがメモリ上に整列し、戦闘態勢で待機している)- メリット: 圧倒的に最速。 プロセスの起動・消去という「無駄なCPU処理」が1ミリも発生しないため、どんなアクセスに対しても0秒（ミリ秒世界）で即レスポンスを返します。
- デメリット: アクセスがゼロでも、設定したメモリ（今回は14GB）を常時占有し続けます（メモリ富豪専用）。
💡 結論：物理サーバーを握っているなら「static」一択
WordOpsのデフォルトが ondemand なのは、格安VPS向けの安全マージン（デチューン設定）でしかありません。 物理メモリを豊富に積んだモンスターサーバーにおいて、プロセスの起動・終了を繰り返す ondemand は、CPUのパワーを無駄遣いする最大のボトルネックです。 贅沢にメモリを常時確保できるのであれば、プロセス生成のオーバーヘッドが完全にゼロになる static 運用こそが絶対正義です。
4. 【実践編】設定ファイルを書き換える
黄金式で導き出したプロセス上限値 280 を、対象サイト専用の設定ファイルとして新規に反映させていきます。 pm = static でプロセスを数百個レベルまで引き上げる場合、デフォルトのシステム制限（ファイル記述子の上限など）に衝突し、プロセス起動時に Too many open files エラーを発生させてPHP-FPMが起動しなくなります。 そのため、プロセスの増強と同時にシステム側のリミッター解除を事前に実施します。
Step 1. systemd のリミッター解除（起動猶予時間・ファイル上限）
大量のプロセスを static モードで一斉に展開する際、OS側による「プロセス起動時のタイムアウト」および「ファイルオープン制限（NOFILE）」によるブロックを防止するため、systemd の設定をオーバーライドします。
sudo systemctl edit php8.3-fpmエディタに以下を追記して保存・終了します。
[Service]
TimeoutStartSec=infinity
LimitNOFILE=1024000
LimitNPROC=1024000# systemd設定の再読み込み
sudo systemctl daemon-reloadStep 2. PHP-FPM グローバル設定のチューニング
PHP-FPM全体の管理プロセスがシステム制限を超えてファイルを開けるよう、グローバル設定ファイル（/etc/php/8.3/fpm/php-fpm.conf）を調整します。
sudo nano /etc/php/8.3/fpm/php-fpm.conf[global] セクション内にある以下のパラメータを探し、先頭のセミコロン（;）を外して値を書き換えます。
; グローバルでのファイル記述子上限を同期
rlimit_files = 1024000Step 3. メインサイト専用プールファイル（main.conf）の新規作成
🚨 重要（ソケット競合の回避）:
既存のデフォルトプール（www.confなど）と同じソケット名（php83-fpm.sock）をそのまま使うと、ソケットの奪い合い（Address already in use）でPHP-FPMが起動エラーを起こします。そのため、サイト名固有のソケット名（例: test-site.sock）に独立させて作成します。
sudo nano /etc/php/8.3/fpm/pool.d/test-site.conf中身に以下を記述して保存します。
[test-site]
user = www-data
group = www-data
listen = test-site.sock
listen.owner = root
listen.group = www-data
; ====================================================================
; 🔥 【極限高速化・リミッター解除】
; メモリ48GBからシステム・キャッシュ枠を引いた28GBを本館・別館で折半（14GB）
; プロセス生成のオーバーヘッドをゼロにするため static 280固定で回す！
; ====================================================================
pm = static
pm.max_children = 280
ping.path = /ping
pm.status_path = /status
pm.max_requests = 1500
request_terminate_timeout = 300
chdir = /
prefix = /var/run/php
listen.mode = 0660
; 🚨 接続待ち上限（バックログ）を安全な最大値へ引き上げる
listen.backlog = 32768
catch_workers_output = yes
php_admin_value[open_basedir] = "/var/www/:/usr/share/php/:/tmp/:/var/run/nginx-cache/:/dev/urandom:/dev/shm:/var/lib/php/sessions/"※上記でソケット名を test-site.sock に変更したため、Nginx側のPHP処理設定（common/php83.conf 等）がこのソケット名（またはパス）を指していることを必ず確認してください。
🔍 主要パラメータの裏側の役割と仕組み
書き換えた重要パラメータが、サーバーの内部で何をしているのかを解説します。
1. pm = static（プロセス常時固定化）
- 裏側の動き: 通常の「オンデマンド（省エネ）」を廃止し、サーバー起動時に指定した数（280個）のプロセスをすべてメモリ上に展開し、常時待機させます。
- 効果: リクエストが来るたびにプロセスを「作っては消す」というCPUのオーバーヘッドを完全に排除し、アクセスの応答速度（TTFB）を限界まで引き上げます。
2. pm.max_children = 280（プロセス数の上限値）
- 裏側の動き: 常時起動しておくプロセスの「数」を指定します。
- 効果: 2章の黄金式（14GB ÷ 50MB）で計算した、別館に割り当てられる限界値です。この数値を闇雲に大きくしすぎると、メモリからプロセスが溢れてサーバーがクラッシュ（OOM Killer発動）するため、安全かつ極限まで攻めた「280」を指定しています。
3. listen.backlog = 32768（接続待ちの上限値）
- 裏側の動き: 万が一、常時待機している280プロセスを上回る瞬間的な超アクセス（SNS砲など）が来た際、処理しきれない接続を一時的に並べておく「行列の長さ（キュー）」を指定します。
- 効果: この数値を適切に引き上げておくことで、アクセスが殺到した際にも接続を門前払い（502 Bad Gateway）にすることなく、行列に並ばせて順番に超高速処理していくことができます。
5. 反映と動作確認（ヨシ！）
設定ファイルの保存が完了したら、いよいよサーバーにこのモンスターエンジンを反映させ、実際にプロセスが立ち上がっているか確認してみましょう。
① 設定の反映（PHPの再起動）
以下のコマンドを実行して、PHP-FPMサービスに新しい設定を流し込みます。
sudo systemctl restart php8.3-fpm② 稼働状況の確認（プロセスのカウント）
無事に起動したら、実際にメモリ上で指定したプロセスたちが戦闘態勢に入っているか、以下のコマンドでプロセス数をカウントしてみましょう。
ps aux | grep php-fpm | grep -v grep | wc -l実行した結果、ターミナルに 282 前後の数値がビシッと返ってくれば、無事リミッター解除は成功です！
🔍 なぜ「282」プロセスなのか？（数値の内訳）
「設定したのは pm.max_children = 280 なのに、なぜ 282 個のプロセスが動いているの？」と疑問に思うかもしれません。この数字にはちゃんとした内訳があります。
- 本館（main）用の管理親プロセス： 1個
- 別館（sub）用の管理親プロセス： 1個
- 今回設定した別館用の常時待機ワーカープロセス： 280個
- 合計： 282個
これで、どれだけ瞬間的なアクセス集中が発生しても、1ミリの遅延もプロセス生成のCPUオーバーヘッドもなく、メモリ空間の上でダイレクトにリクエストを瞬殺して捌き切る「無敵のWordPress環境」が整いました。
実際に「static 280固定」にしたWordPressの圧倒的なレスポンス速度を、ブラウザから体感してみてください。
6. 【応用編】1台のサーバーで「複数サイト」を運用する場合の設計と設定
単独サイトでの static 運用の凄さを体感したところで、さらに「本館」と「別館」のように、1台の物理サーバーで複数のWordPressサイトを並行運用する場合の設計に進みましょう。
PHP-FPMをサイトごとに分けることで、特定サイトへのアクセス集中がもう片方を引きずり下ろす「リソースの奪い合い」を防ぎ、セキュリティ的にも強固に隔離することができます。
🧮 複数サイトにおけるメモリの「分配計算」
2章の「黄金式」を使い、全体の合計が「PHP-FPM用の総メモリ枠（28GB）」を超えないように各サイトの max_children を調整します。
| 配分パターン | 本館（メイン）の割り当て | 別館（サブ）の割り当て |
| 均等配分（折半）★今回採用 | 14GB（280プロセス） | 14GB（280プロセス） |
| 傾斜配分（メイン集中） | 19.6GB（392プロセス） | 8.4GB（168プロセス） |
🛠️ 複数プールへの分割とNginxの設定手順
サイトごとにプール設定ファイルを作成し、それぞれ独立したソケットでNginxと接続させます。
Step 1. プール設定ファイルをサイト別に作成する
/etc/php/8.3/fpm/pool.d/ 配下に、サイトごとの設定ファイルを新規作成します。
- 本館用：
/etc/php/8.3/fpm/pool.d/main.conf - 別館用：
/etc/php/8.3/fpm/pool.d/sub.conf
中身は4章で作成した設定をベースに、以下の共通テンプレートを使い、サイトごとの個別の値（プール名、ソケット名、プロセス数、ディレクトリ）を当てはめて記述します。
; 🚨 [プール名] は各ファイルでユニークにする（例：[main-php83] / [tech-php83]）
[site-php83]
user = www-data
group = www-data
; 🚨 [ソケット名] もプールごとに個別定義（例：php83-fpm-main.sock / php83-fpm-tech.sock）
listen = php83-fpm-site.sock
listen.owner = root
listen.group = www-data
pm = static
; 分配計算に基づいて max_children を指定（折半設計の場合は 280）
pm.max_children = 280
ping.path = /ping
pm.status_path = /status
pm.max_requests = 1500
request_terminate_timeout = 300
chdir = /
prefix = /var/run/php
listen.mode = 0660
listen.backlog = 32768
; catch_workers_output = yes (大量プロセス稼働時のパイプ上限衝突を防ぐため無効化)
; open_basedir によりプロセスがアクセス可能なディレクトリを当該サイト配下のみに制限
php_admin_value[open_basedir] = "/var/www/サイトのディレクトリ/:/usr/share/php/:/tmp/:/var/run/nginx-cache/:/dev/urandom:/dev/shm:/var/lib/php/sessions/"Step 2. Nginx側のソケット接続設定の変更
PHP-FPMの通信ソケット分離に伴い、各サイトのNginxバーチャルホスト設定（/etc/nginx/sites-available/ 配下の設定ファイル）において、STEP 1で定義した各プール専用のソケットを参照するように書き換えます。
# 本館（main.com）のNginx設定例
location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php83-fpm-main.sock; # 本館用プールソケット
}
# 別館（tech.com）のNginx設定例
location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php83-fpm-tech.sock; # 別館用プールソケット
}Step 3. 再起動とマルチプール動作検証
NginxとPHP-FPMをそれぞれ再起動し、変更を適用します。
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginxシステム制限およびパイプライン設定の事前調整が適用されているため、エラーを生じることなくマルチプール構成が起動します。
稼働確認としてプロセス数を再カウントします。
ps aux | grep php-fpm | grep -v grep | wc -l出力結果が 564 前後になっていれば、両プールが設計通りのプロセス数で完全に独立並行稼働しています。
- 管理親プロセス（本館・別館用）： 4個前後
- 本館用ワーカープロセス（static）： 280個
- 別館用ワーカープロセス（static）： 280個
- 合計： 564個前後
🏆 前編のまとめ：マシンスペックを100%解放した「極限の爆速環境」の誕生
お疲れ様でした！これで、格安VPS向けの「安全運転（デチューン）」を脱却し、あなたの持つ強力なマシンスペックと潤沢な物理メモリをフルに引き出す「PHP-FPMのリミッター解除とプロセス最適化チューニング」は完全に完了です。
ここまでの設定によって、ご自身のサーバー環境に合わせて設計した潤沢なワーカープロセス（今回の実例では単独サイトで280個、複数プールによる並行運用なら合計560個以上）が、メモリ空間に美しく整列しました。
どんな瞬間的なアクセス集中に対しても、CPUに余計なフォーク負荷（プロセスの生成・消滅）をかけることなく、すべてのリクエストを「ミリ秒世界」で即レスする圧倒的な戦闘態勢が整っています。
サーバーが持つ潜在能力をNginxとPHP-FPMのロジックによって100%解放したこの環境のレスポンスは、一度体感するとデフォルト設定には二度と戻れないほどの快感です。
しかし、インフラ全体のボトルネックを完全に消滅させるための戦いは、まだ始まったばかりです。
この前編で、メモリ空間の上に大量のプロセスを展開して「同時処理能力」を爆発させましたが、PHPの処理スピードが極限まで高まった結果、次にWordPressのデータを読み書きする「ストレージ（SSD）のI/O速度」が新たなボトルネックとして浮上してきます。
そこで次回の中編では、潤沢な物理メモリをさらに贅沢に使い倒し、「特定データを完全にRAMディスク（高速プール）化してSSDの寿命を10倍に延ばしつつ、速度をさらに異次元へと引き上げる自動化設定」へと駒を進めます。
物理サーバーのモンスターリソースをフル活用した「真の完全体」を目指して、このまま一気に駆け抜けていきましょう！
次回、『WordOps極限爆速化チューニング【中編】』。メモリ富豪にしか許されない、至高のストレージ超絶高速化編は2026年8月2日公開です。お楽しみに！
コメント