〜高負荷下での安定化とキャッシュ最適化〜

2025年11月、WordPress 環境（KUSANAGI9 + nginx + PHP-FPM8.1）において、長時間稼働後に sporadic な php-fpm クラッシュやレスポンス低下が発生。

調査の結果、FPM のプロセス管理設定（pm系パラメータ）の過大設定が主因と判明した。

1. 環境概要

OS：CentOS Stream 9
PHP-FPM：8.1
メモリ：3.6GB
Webサーバ：nginx129
キャッシュ：fcache 有効、bcache オフ（OGP対策のため）

2. 問題点（初期状態）

デフォルトの構成は以下の通りだった。

pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

ログには以下のような警告が散発していた。

WARNING: [pool www] server reached pm.max_children setting (50)
WARNING: [pool www] seems busy (spawning 32 children)

また、子プロセスの平均RSS（メモリ常駐サイズ）は約208MBに達しており、実メモリ3.6GBの環境では約7並列で40%を超える計算になる。

50並列という設定は明らかに過剰で、スワップやクラッシュを誘発する状態だった。

3. 調整の流れ

安全上限を算出し、FPMパラメータを段階的に縮小。最終的な設定は以下。

pm.max_children = 8
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 300

pm.max_children を 8 に下げた際には整合性に注意が必要で、待機系の値（start / spare）を同時に下げなければ FPM は起動しない。

つまり、pm.max_children だけ8に下げてしまうと、503真っ白画面の恐怖が待っているのだ（実際になった笑）

この調整により、構文エラーやサービス停止を防ぎつつ安定稼働に成功した。

4. チューニングの要点

項目 調整方針 効果

max_children 50 → 8 メモリ超過防止・安定化
start_servers / spare 10,5,15 → 3,2,4 アイドル時メモリ削減
max_requests 500 → 300 メモリ断片化の定期解消
fcache TTL60m / inactive120m / size2G PHP到達率を最小化

5. 結果

error.log に「server reached」や「emergency」警告なし
子プロセス平均RSS 200MB前後で安定
nginx レイヤでの fcache が有効稼働し、PHP負荷を大幅に軽減
長期稼働でもクラッシュ・再起動なし

6. メリット・デメリット

メリット

メモリリーク・スワップの抑制
PHP-FPM の長期安定運用
サイト停止リスクの解消

デメリット

同時に8件以上のPHP実行要求が発生すると一時的に待ち発生
管理画面での操作が集中する時間帯に軽いレスポンス遅延の可能性

7. 今後の運用方針

現行の「8」をベースラインとし、状況を見て 10→12 に段階引き上げ
高負荷時は fcache のヒット率を優先的に監視
PHP-FPM エラーログを watch コマンドで常時簡易監視
バックアップ済み設定により即時ロールバック可能

参考：復旧コマンド（デフォルト値に戻す）

sed -i ‘s/^pm\.max_children\s*=.*/pm.max_children = 32/’ /etc/opt/kusanagi/php-fpm.d/www.conf
sed -i ‘s/^pm\.start_servers\s*=.*/pm.start_servers = 10/’ /etc/opt/kusanagi/php-fpm.d/www.conf
sed -i ‘s/^pm\.min_spare_servers\s*=.*/pm.min_spare_servers = 5/’ /etc/opt/kusanagi/php-fpm.d/www.conf
sed -i ‘s/^pm\.max_spare_servers\s*=.*/pm.max_spare_servers = 15/’ /etc/opt/kusanagi/php-fpm.d/www.conf
systemctl restart php-fpm
kusanagi nginx –reload

結論

少メモリ環境では「高並列＝速い」とは限らない。

pm.max_children を減らすことでリソース効率を最大化し、結果的に落ちないサーバーへと変貌した。

FPM チューニングは“数を増やす”のではなく、“適正値を見極める”ことが肝要である。

PHP 8が抱える課題と懸念点

PHP 8は、言語としての完成度を高めた反面、現場レベルではいくつかの課題を抱えている。

特に中小規模サイトやVPS環境では、それが「劣化」として体感されることも少なくない。ワイのように。

1. 軽量性の喪失

PHP 7までの軽快さは失われ、PHP 8ではメモリ常駐量が増大した。
JIT（Just-In-Timeコンパイル）や新しい型システムが内部的に多くのリソースを消費するため、低メモリ環境では逆に遅くなる場合もある。

つまり「高速化＝軽量化」ではなく、「高性能化＝重量化」へと方向転換した。

2. 設定依存度の増加

PHP 8ではエンジンの動作がシステム設定に強く依存する。

PHP-FPMのプロセス制御（pm系）、OPcache、JIT、キャッシュ層などを旧バージョンのまま流用すると不安定化しやすい。

同じPHPでも「調整の有無」で安定性が天と地ほど変わる。

3. 互換性問題の顕在化

多くのプラグインやテーマがPHP 8の構文・型仕様に完全対応していない。

Deprecated WarningがFatal Errorに昇格するケースもあり、「表面上は動くが裏で落ちる」という現象を引き起こしやすい。

4. 専門知識を要する環境設計

PHP 7時代は“入れたら動く”が常識だった。

しかしPHP 8では、サーバー設計・キャッシュ戦略・プロセス管理を理解して初めて性能が出る構造となっており、初心者には敷居が高くなった。

適切なチューニングができないと、せっかくの性能向上が裏目に出る。

5. 小規模サイトとのミスマッチ

高トラフィック向けには優秀だが、少メモリVPSや共有サーバーではオーバースペック気味。

これまで安定していたWordPress環境でも、設定を見直さなければ落ちやすくなる。

PHP 8は「よりモダンで、より正確な言語」になったが、その代償として「扱う側に高度な知識と調整力を要求する言語」へと進化した。

安定性を求めるなら、運用者自身が設定・監視・最適化の一連を理解することが不可欠である。

つまり、PHP 8とは“誰でも動かせるPHP”から、“扱えば強いPHP”への転換点なのかも知れぬ。