【KUSANAGI9】PHPメモリ不足によるWordPressエラーと復旧の記録（2025年10月）

今回のログに出ていた主要エラーは、ほぼ「PHP8で厳格化された挙動」によるものが多いです。PHP7では“うやむや”に動いていたコードが、PHP8だと即Warning/致命エラーになります。

chatGPTより

と、まあこんな感じで、WordPressのサーバー引越しから一ヶ月近くたっても、定期的に謎の「重大なエラー」連発でずーっとエラー修正。ここまできてようやく一番の原因が７に比べて厳しすぎるPHP8の挙動のせいだとわかりました。

まあ以前は良くも悪くも「“うやむや”に動いていた」ということなんですが（笑）

つまりエラーの大半が、記述が厳しくなったことによる膨大なエラーログ（数日で数ギガ単位）や、phpのメモリ不足（デフォルトで128MB）が原因だったのでした。

128MBは以前からそうだったのですが、記述が厳しくなったことによりエラーが出ると圧迫もされやすくなり

•PHP7でもデフォルトは128MBだったが、「厳密チェックが甘く実質的に動いていた」
•PHP8では同じ128MBでも、構文・キャッシュ・型管理で実メモリ使用が増加
•そのため、実運用では512MB〜1024MBが新しい“現実的な標準”

ということでした。chatGPTがなかったらワイのようなコマンドコピペ野郎は永遠に気づかなかったであろう・・・

何度エラーを直しても、色々な要因でメモリ不足となり、結局謎の真っ白画面連発だったのです😅

ざっくり内訳（これまでの実例）
■ 今日の発生概要
■ 環境情報
■ 主なエラーログ
■ 対応手順
■ 復旧結果
■ 原因と考察
■ 今後の対策
■ 補足

ざっくり内訳（これまでの実例）

• Undefined array key（例: index_category1, show_footer_bar, show_bookmark）
→ PHP8は未定義キー参照を黙認しない。$arr[‘key’] ?? ” / isset($arr[‘key’]) が必須。

• Trying to access array offset on value of type bool（wp_get_attachment_image_src() などが false を返すケース）
→ 返り値チェック必須：if ($img && is_array($img)) { … }

• Undefined variable（$user_ID など古いグローバル）
→ いまは get_current_user_id() を使う／変数の存在チェックを入れる。

• メモリ枯渇（Allowed memory size exhausted）
→ エラー雪崩＋キャッシュのDB依存で負荷が増幅。memory_limit 512Mへ、bcache再設定で収束。

• キャッシュ関連の致命（advanced-cache.php / wp_*_site_cache が無い）
→ KUSANAGIのbcacheがDB方式でテーブル未作成 → ファイル方式へ切替で解消方向。

■ 今日の発生概要

2025年10月下旬、WordPress（マルチサイト構成）を稼働中のサーバー環境で、断続的にページ応答が停止。
管理画面・トップページの両方で「504 Gateway Time-out」「応答がありません」などのエラーが発生。
ログを調査した結果、PHPのメモリ不足（Allowed memory size exhausted）が原因であることが判明。

■ 環境情報

KUSANAGI Version: 9.6.14-1.el9
OS: CentOS Stream 9
Webサーバー: nginx129（active）
PHP: php-fpm 8.1.33（active）
DB: MariaDB 10.6.23（active）
WAF: off
SELinux: off（permanent）
WordPress構成: マルチサイト
使用テーマ:
親テーマ: CORE (tcd027)
子テーマ: core_tcd027_〇〇〇（カスタム版）

■ 主なエラーログ

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)
in /home/kusanagi/〇〇〇/DocumentRoot/wp-includes/class-wpdb.php on line 2322

このログは128MBのメモリ制限（PHPデフォルト値）に達した際に発生。
特に archive.php や index.php 周辺でループが重なり、FPMプロセスがリソースを使い果たしていた。

■ 対応手順

① 現在のメモリ制限を確認

php -i | grep -i ‘^memory_limit’

=> memory_limit => 128M => 128M

② 設定ファイルを特定

php –ini | grep “Loaded Configuration File”

=> /etc/opt/kusanagi/php.d/php.ini

③ バックアップ後、512MBに変更

cp -a /etc/opt/kusanagi/php.d/php.ini /etc/opt/kusanagi/php.d/php.ini.bak.$(date +%F-%H%M%S)
sed -i ‘s/^memory_limit\s*=\s*.*/memory_limit = 512M/’ /etc/opt/kusanagi/php.d/php.ini

④ php-fpmをリロード

systemctl reload php-fpm
php -i | grep -i ‘^memory_limit’

=> memory_limit => 512M => 512M

⑤ WordPress CLIでも確認

wp eval ‘echo ini_get(“memory_limit”), “\n”;’ –path=/home/kusanagi/〇〇〇/DocumentRoot

=> -1（制限なし、実質512MB適用）

■ 復旧結果

・PHP-FPMのメモリ上限を512MBに引き上げ後、エラーは完全解消。
・nginx / php-fpm / mariadb すべて安定稼働を確認。
・OGP・サムネイル生成も正常化、以前の子サイトOGP不具合も解消。
・CPU負荷は軽微に上昇したが、安定性が大幅に向上。

■ 原因と考察

1. PHP更新時に php.ini がデフォルト128Mに戻っていた。
2. OGP・キャッシュ・クエリ結合などの重処理でメモリ不足。
3. 子テーマ内（core_tcd027_〇〇〇）のループ構造が重い。

■ 今後の対策

・/etc/opt/kusanagi/php.d/php.ini.bak を保持し、アップデート後に確認。
・opcache.memory_consumption を192〜256MBへ最適化検討。
・FPM設定（pm.max_children）の見直し。
・COREテーマのPHP8完全対応版へ改造。またはめんどいのでテーマごと変更も検討。