ワードプレス

WordPress Opcache: よくある設定ミスとその解決策

ワードプレス opcache が有効になっていることが多いが、正しく設定されていることはほとんどない：少なすぎるメモリ、狭すぎるファイル制限、不正確なタイムスタンプのチェックは、キャッシュ・ミスや顕著なロード時間に直接つながります。このガイドでは、典型的な設定ミスを紹介し、信頼できるガイド値を示し、キャッシュが動作しているのか、CPUをビジー状態にしているのかを確認する方法を説明します。.

中心点

以下の重要な点は、誤った設定を素早く認識し、修正するのに役立ちます。.

メモリ現実的な次元のopcache.memory_consumption
ファイルopcache.max_accelerated_filesをコードベースに合わせて設定する。
ストリングスWordPressのopcache.interned_strings_bufferを増やす
タイムスタンプvalidate_timestampsとrevalidate_freqを適切に選択する。
モニタリングヒット率、リスタート、キーを定期的にチェック

Opcacheの設定がWordPressを遅くする理由

と一緒に オプキャッシュ PHPはコードを一度コンパイルした後、バイトコードを作業メモリから直接配信しますが、不正確な値はこの利点を蒸発させます。キャッシュが小さすぎると、常にエントリが上書きされ、再コンパイルが頻発し、負荷がピークに達します。また、„accelerated files“ が少なすぎると、必要な PHP ファイルがすべてキャッシュに入りきらず、キャッシュミスを避けることができなくなります。インターンされる文字列が小さすぎると、WordPressは文字列の繰り返しで効率を失い、これは特に多くのプラグインで顕著です。私は、ヒット率、キャッシュされたキーの数、再起動の数によってこのような効果をチェックしている。.

メモリを正しくサイジングする： opcache.memory_consumption

をセットした。 opcache.memory_consumption というのも、最近のWordPressはすぐにこれを超えてしまうからだ。小規模なブログの場合は128MBから始め、大規模なサイトの場合はエントリーが連続的に移動しないように256～512MBを計画している。サイトが大きくなるにつれて、Opcacheの空きメモリと再起動のカウンターをチェックし、再起動の増加やヒット率の低下があれば、段階的に値を増やしていく。プラグインのアップデート後に短い負荷テストを行うことで、キャッシュに十分な容量があるのか、それともすでに限界で動作しているのかを確認することができます。新しいシステムをセットアップする場合、このコンパクトな OPcacheの設定さらにオリエンテーションの値を追加して、実際のファイルのボリュームに合わせる。.

ファイルインデックスを正しく設定する： opcache.max_accelerated_files

と一緒に opcache.max_accelerated_files キャッシュが管理できるPHPファイルの数を定義し、常に実際のファイル数より多い値を設定する。サーバー・サイドで、例えば „find .-iname „*.php“ | wc -l“」などでサーバー側で数を決定し、更新後にWordPressがこの制限にぶつからないように、20～30パーセントのバッファを追加する。デフォルトが約3000のままだと、キャッシュの可能性を逃してしまい、負荷がかかったときに不安定なパフォーマンスになってしまう。大規模なインストールでは、プラグインやテーマ、必ず使うモジュールにもよりますが、10,000から32,500の範囲になることがよくあります。キャッシュされたキーの数を制限値と比較し、実際のアクセスでのヒット率を観察することで結果を検証しています。.

隠れたボトルネックとしての内部文字列バッファ

仝 opcache.interned_strings_buffer 特にWordPressはインターンされた文字列から大きな恩恵を受けているが、多くの人が見落としている。テーマやプラグインは多数の文字列を繰り返し使用するため、16-32MBの値は実際にうまく機能する。特に大規模なセットアップの場合、メモリの使用量と文字列の統計が示すように、段階的に64MBまで増やします。バッファが小さすぎると、多くの似たような文字列を1つのメモリロケーションにマージするようなバリデーションが行われなくなる。調整後、同じトラフィックで再起動が減り、全般的なレスポンスタイムが安定しているかどうかをチェックする。.

タイムスタンプを理解する：validate_timestampsとrevalidate_freq

と一緒に opcache.validate_timestamps Opcacheがファイルの変更を自動的に認識するかどうかを制御しています。これはアップデートのある生産的な環境では重要なことです。validate_timestampsを1のままにしておき、通常はrevalidate_freqを60秒に設定することで、変更されたプラグインがハードディスクを常時チェックすることなく、速やかに稼動するようにしている。デプロイスクリプトでは、誤解を避けるために重要な変更を即座に有効にしたい場合は、PHP-FPMのリロードを計画します。アクティブなエディターのタイムスタンプをオフにすると、フロントエンドで古い成果物やエラーが発生し、割り当てが難しくなる危険性があります。コントロールに関するより深い実用的な質問については、クリーンなキャッシュの無効化, これはリリースごとに繰り返し適用している。.

重要なモニタリングヒット率、キー、再起動

私はその成功を次のように評価する。 オプキャッシュ というのも、数値はすぐに誤った仮定を露呈するからである。少なくとも99パーセントのヒット率は、ほとんどのリクエストがバイトコードにヒットし、リコンパイルされないことを示している。再スタートが増えたり、キャッシュされたキーの数が限界に達したら、メモリやaccelerated-filesの値を調整する。キャッシュメモリが断片化するとパフォーマンスが突然低下することがあるので、メモリの断片化も監視しています。プラグインのアップデート後、私はキーの数値を再度チェックし、キャッシュが一貫してパフォーマンスを維持し、負荷がかかったときだけ落ちないようにしています。.

opcache_get_status の実際：重要な数値の読み方

構成を素早く把握するために、私は最も重要なフィールドを読み上げ、自分の目標と比較する：

opcache_statistics.hits/misses比率はヒット率を決定する。目標：実トラフィック下で99 %以上。.
opcache_statistics.num_cached_scripts以下であること opcache.max_accelerated_files は残る。
memory_usage.used_memory/free_memory/wasted_memory。メモリが不足しているか、断片化されているかを示す。.
opcache_statistics.oom_restarts そして ハッシュ・リスタートそれが増えたら、メモリやファイルを増やす。.
interned_strings_usage.buffer_size/使用メモリ文字列バッファの寸法が十分かどうかを示す。.

シェルや管理ルートで実行する小さなヘルパーは便利だ：

php -r 'var_export(opcache_get_status(false));'.
php -i | grep -i opcache
php -r 'echo count(array_filter(get_included_files(), fn($f) => substr($f,-4)===".php");'

これらの数字に基づいて、メモリを増やすか、ファイルインデックスを拡張するか、再検証の頻度をリクロックするかを決める。.

シナリオ別の推奨オペキャッシュ値

一般的な推薦をする代わりに 標準値 をコードベースに追加し、バリアントを同等に保ちます。小規模から中規模のサイトでは、多くのエクステンションを持つショップよりも必要なリソースが明らかに少なくなります。私は開発環境を設定し、本番環境でファイルチェックを行う間、変更が遅延なく見えるようにします。次の表は、通常の開始値をまとめたもので、モニタリングで微調整しています。もしあなたが成長を計画しているのであれば、リリースがすぐに再計画を余儀なくされないように、バッファを持って計算する方が良いでしょう。.

シナリオ	opcache.memory_consumption	opcache.max_accelerated_files	opcache.interned_strings_buffer	opcache.validate_timestamps	opcache.revalidate_freq
小/中	128 MB	10000	16 MB	1	60
大型	256～512 MB	32500	64 MB	1	60
開発	128～256 MB	10000-20000	16～32 MB	1	0

CLI、FPM、WP-CLIのコンテキストにおけるOPcache

すべてではない 周辺環境 はOPcacheを同じように使うので、FPM、Apacheのmod_php、CLIの違いに注意している。WP-CLIのタスクの場合、Opcacheには何のメリットもないことが多いので、enable_cliを0にしておくことが多い。生産的なスタックでは、私はPHP-FPMを使い、calienteのデプロイが無秩序にキャッシュを空にしないように、特にリロードをスケジュールする。CLI経由でPHPスクリプトを起動するCronjobは、最適化されたPHPコードとI/Oの恩恵を受けています。管理者がどこでopcacheが有効になり、どこで有効にならないかを知るために、私はこれらのパスを文書化しています。.

配備後のウォームアップ：コールドスタートを避ける

リリースの後、キャッシュは冷えている。多くのセットアップが一時的に崩壊するのはまさにこの時だ。そこで私は 的を絞ったウォームアップ にある：

FPMのリロード後、私は自動的に重要なルート（ホーム、製品/貢献ページ、検索/ショップフロー）を取得します。.
私はサイトマップや事前に定義したURLリストを使い、一度にすべてを溢れさせるのではなく、100～500ページを波状的にプライム化する。.
CPUのピークを避け、バイトコードが安定してロードされるように、ウォームアップのリクエストを1-2分かけて分散させる。.

これによって、実際のユーザーがコンパイル作業の代金を支払うことを防ぐことができる。特にショップにとっては、このステップによってデプロイ直後のレスポンスタイムのピークを抑えることができる。.

JIT、プリロード、ファイルキャッシュ：WordPressのための分類

よく使われる用語なので、WordPress用に分類してみた：

JIT (opcache.jit)典型的なWPのワークロード（I/Oが多く、数値的なホットループが少ない）では、JITは通常、測定可能な利益をもたらさない。私は通常、WordPressの本番環境ではJITをスキップします。.
プリロード (opcache.preload)明確で安定したフレームワークと相性が良い。WordPressはプラグインやテーマを動的にロードする。プリロードはエラーが起きやすく、メンテナンスが必要だ。私は、オートロードの連鎖を正確に制御できる場合にのみ、これを使用する。.
ファイルキャッシュ (opcache.file_cache)バイトコードがディスクに残ってしまうので、CLIジョブや短期再起動を軽減できる。しかし、FPMファーストのスタックでは、共有メモリキャッシュを優先する。ファイルキャッシュは、ツールやcronjobsのための補助的なものだ。.

ブラックリスト、セキュリティ、コントロール

Opcacheの設定も管理している 安全性と安定性の理由 クリーンだ：

opcache.restrict_apiOpcacheの関数（例えばReset）を呼び出す権限のある人を制限します。管理用スクリプトのみが配置されるパスをここに設定します。.
opcache.blacklist_filename頻繁に書き換えられるファイル/ディレクトリ（コードジェネレーターなど）を除外し、スラッシングを防ぐ。.
opcache.save_comments=1WP/プラグインはしばしばdocblocks/annotationに依存しているので、アクティブでなければならない。コメントがないと、メタデータが失われます。.
opcache.consistency_checksハッシュの衝突や不整合を検出するためにステージングでのみ有効にしてください。.

; 例
opcache.restrict_api=/var/www/html/opcache-admin
opcache.blacklist_filename=/etc/php/opcache-blacklist.txt
opcache.save_comments=1

マルチサイト、マルチプロジェクト、PHP FPMプール

複数のサイトがFPMプールを共有すると、同じOpcacheを「奪い合う」ことになる。そのため 資源集約型プロジェクト 自分たちのプールで：

各プールに別々のINI値を設定する。こうして、サイトサイズに応じて正確にmemory_consumptionを調整する。.
バイトコードの相互置換はない。一方のサイトの更新が他方のキャッシュをフラッシュすることはない。.
より良い故障の特定：再起動とヒット率はアプリケーションごとに解釈できる。.

マルチサイトのセットアップでは、特定のサブサイトが非常に多くのファイル（ビルダー、WooCommerce、ページビルダー）を持ち込むかどうかも監視しています。それに応じてファイルインデックスを調整し、より多くのバッファを計画します。.

メモリの断片化を抑える

十分な総メモリがあっても、断片化されたキャッシュは突如として発生することがある。 パフォーマンス低下 原因だから私は観察している：

無駄メモリー そして opcache.max_wasted_percentageしきい値を超えると、Opcacheは再起動する。このような再起動が累積するようなら、私はメモリを増やし、特定のデプロイが多くの小さなファイルを変更していないかチェックする。.
コード・レイアウト頻繁に更新される大規模なプラグインは、より多くの断片化を引き起こす。絶え間ないマイクロアップデートの代わりに、バンドルされたリリースウィンドウが役立ちます。.
巨大なコードページ (opcache.giant_code_pages)：システムが巨大ページをサポートしている場合、断片化とTLBミスを減らすことができる。プラットフォームが適切に設定されている場合にのみ設定する。.

開発とステージングのワークフロー

開発中 変更の可視性 最大限のパフォーマンスそのため、私は一緒に仕事をしている：

validate_timestamps=1 そして revalidate_freq=0, 変更がすぐにわかるように。.
INIファイルを環境(DEV/Stage/Prod)ごとに分けて、偶発的な引き継ぎを防止。.
JITを無効化し、enable_cliをオフにして、WP-CLIが高速で決定論的であり続けるようにした。.
デバッグ拡張機能（Xdebugなど）は、キャッシュや実行時の挙動を大きく変えるため、本番環境では一貫して無効にしている。.

コンテナでは、マウントのタイプ（ネットワーク／バインドマウントなど）に注意を払う。そうしないと、タイムスタンプの頻繁な変更が不要な再検証の引き金になるからだ。.

エラーパターンを明確に分類する

典型的な症状には明確な原因があることが多い：

アップデート後の突然の500秒再起動、断片化、および FPM の再読み込みがコードスワップ後に正確にトリガーされたかどうかを確認する。.
一貫性のないフロントエンドvalidate_timestampsが正しくないか、選択した再検証ウィンドウが大きすぎる。.
永久に低い命中率ファイル・インデックスやメモリが小さすぎる。時折、多くの「ミス」が発生するのは、ビルド・アーティファクトが常に変化していることを示している。.
遅いCLIジョブenable_cli=0は通常正しい。SHMのオペキャッシュではなく、最適化されたコードやファイルキャッシュが役に立つ。.

最初の30分間の簡単なチェックリスト

PHPファイルと max_accelerated_files %バッファーを20-30個使用。.
メモリ消費 文字列バッファは16-64MB。.
validate_timestamps=1 そして 再評価 を60に増やした。.
デプロイ後: FPM をリロードし、ウォームアップルートを起動し、opcache_get_status() をチェックする。.
再起動、ヒット率、wasted_memoryを監視し、異常が発生した場合は目標を定めて調整を行う。.
セキュリティ restrict_api セット、, save_comments=1 必要であれば、問題のあるパスがブラックリストに登録されるようにする。.
オプション：大規模なサイトではFPMプールを分けて、キャッシュが互いにずれないようにする。.

体系的なトラブルシューティング：症状から原因へ

を始める。分析常にキーとなる数字で：ヒット率が落ちたり、リスタートが増えたり、キーが限界に達したら、具体的なステップを導き出す。キャッシュが一杯になったらmemory_consumptionを増やし、ファイルが限界に達したらmax_accelerated_filesを増やす。デプロイ後に矛盾したフロントエンドのステータスが表示されたら、validate_timestampsとFPMのリロード時間をチェックする。500が散発的に発生する場合は、設定を微調整する前に、フラグメントキャッシュをチェックし、エラーログを消費する。各変更の後、主要な数値とロード時間が一貫して一致するまで再度測定します。.

簡潔な要約

強い ワードプレス-パフォーマンスは、十分に大きなopcache、アクセラレーションされたファイルに対する適切な制限、適切に選択された内部文字列バッファから始まる。本番では、タイムスタンプを有効にしておき、チェックを計時し、リリース時のリロードを制御することで、変更が時間通りに反映されるようにしている。ヒット率、リスタート、キーなどのメトリクスは、客観的にどの調整ネジを回すべきかを示してくれるからだ。表の値は出発点ですが、サイトごとにどのように調整するかはモニタリングで決めます。この規律を守れば、PHPから短いレスポンスタイムを確実に得ることができ、トラフィックのピーク時でもCPUをリラックスさせることができる。.