管理

PHP OPcache の詳細な説明：キャッシュを最大限に活用する方法

PHP OPcache は、PHP がコンパイルされた バイトコード メモリに保持し、再解析を省く方法をご紹介します。このガイドでは、OPcache の使用方法についてご説明します。 コンフィグ, 、監視し、微調整して、アプリケーションの反応速度を測定可能に高速化し、負荷のピークを余裕を持って吸収できるようにします。.

中心点

バイトコードキャッシュ CPU負荷とI/Oを削減
パラメータ memory_consumption や max_accelerated_files を意図的に選択する方法
周辺環境 差別化設定：開発、ステージング、本番
モニタリング ヒット率、占有率、立ち退きに利用
展開キャッシュフラッシュを適切に連携させる

OPcache の仕組み：再コンパイルではなくバイトコードを使用

通常、PHP はリクエストごとにファイルを読み込み、コードを解析して バイトコード, Zend Engine が実行するバイトコードです。OPcache はまさにこの点に着目し、このバイトコードを共有メモリに保存することで、後続のクエリをメモリから直接開始できるようにします。これにより、CPU サイクルとファイルアクセスが減少するため、応答時間が大幅に短縮されます。一般的な設定では、コードベースやトラフィックプロファイルにもよりますが、30% から 70% のパフォーマンス向上が見られます。重要なのは、キャッシュが十分な大きさであり、最も重要なスクリプトが常に メモリ は残る。

Linux、Windows、共有ホスティングで OPcache を確認および有効化

私は常にphpinfo()を確認することから始め、「Zend」を検索します。 オペキャッシュ“「および opcache.enable や opcache.memory_consumption などのキー。Linux では、php-opcache パッケージと conf.d ディレクトリ内の opcache.ini を使用してモジュールを有効にします。 Windows では、php.ini に zend_extension=opcache と入力し、Web サーバーを再起動するだけで十分です。共有ホスティングでは、多くの場合、ユーザー定義の php.ini または顧客メニューから OPcache を有効にします。ボトルネックが発生した場合は、さらに以下も確認します。 PHPのメモリ制限を増やす, OPcache と PHP-FPM が十分な リソース を受け取りました。

主なスイッチについてわかりやすく説明

opcache.enable を使用すると、Web リクエストのキャッシュを有効にします。一方、opcache.enable_cli は CLI ジョブでの使用を制御し、ワーカーキューで有効です。中核となるのは opcache.memory_consumption で、利用可能な共有メモリをメガバイト単位で指定します。設定が少なすぎると、エヴィクションが発生し、再 コンピレーション. opcache.max_accelerated_files は、キャッシュに保存できるファイルの総数を定義します。この値は、プロジェクトのファイル数を十分に上回る値に設定してください。opcache.validate_timestamps および opcache.revalidate_freq を使用して、OPcache がファイルの変更を検証する厳しさを、非常に動的（開発）から非常に控えめ（手動フラッシュによる本番）まで設定します。多くのツールが DocBlocks 依存している。.

開始値とプロファイルの比較

スムーズな導入のために、開発、ステージング、本番環境について明確なプロファイルを設定しています。これにより、コーディング時に迅速なフィードバックサイクルを得られる一方で、本番環境での信頼性の高いパフォーマンスを実現しています。重要なのは、これらの初期値を実際のメトリクスと定期的に照合し、調整することです。大規模な WordPress インストールでは、プラグインやテーマが多くの ファイル 生成します。以下の表は、ヒット率とエヴィクションに基づいて微調整を行う、適切な初期値をまとめたものです。.

セッティング	開発	ステージング/テスト	製造
opcache.enable	1	1	1
opcache.enable_cli	0	0–1	1（CLI ジョブの場合）
opcache.memory_consumption	128～256 MB	256～512 MB	256～512+ MB
opcache.interned_strings_buffer	16～32 MB	32～64 MB	16～64 MB
opcache.max_accelerated_files	8,000～10,000	10,000～20,000	10,000～20,000以上
opcache.validate_timestamps	1	1	0–1 (デプロイに依存)
opcache.revalidate_freq	0～2秒	60～300秒	300+ 秒または 0 (手動チェック付き)
opcache.save_comments	1	1	1
opcache.fast_shutdown	1	1	1

このマトリックスは、実際のプロジェクトは成長の仕方が大きく異なるため、意図的に実用的なものになっています。私はこれらの値から始め、ヒット率、共有メモリの使用率、およびエヴィクションの発生を観察します。負荷の兆候が見られた場合は、まず opcache.memory_consumption を適度に段階的に増やします。その後、ファイル数が快適に収まるまで opcache.max_accelerated_files を調整します。これにより、 キャッシュ 効果的で、問い合わせは安定して順調です。.

環境に応じた設定：開発、ステージング、本番

開発では、コード変更に対する迅速なフィードバックが重要であるため、validate_timestamps=1 および revalidate_freq を非常に低い値、あるいは 0 に設定しています。ステージングでは、現実的な負荷をテストし、結果が後のライブ運用に近づくよう、メモリを多めに設定しています。本番環境では、デプロイメント後にキャッシュを意図的にクリアする場合、チェックの頻度を上げたり、タイムスタンプを完全に無効にしたりします。CLI ベースのワーカーについては、enable_cli=1 を有効にして、繰り返し実行されるジョブも バイトコードキャッシュ メリットがあります。これにより、各環境は、反応時間に驚きがなく、まさに私が必要とする動作を生み出します。.

多くの場合、違いを生む高度な設定

基本パラメータに加えて、安定性と安全性を高め、副作用を最小限に抑えるためのスイッチがあります。

opcache.max_wasted_percentage: OPcache がメモリの内部再構築を開始する断片化の程度を定義します。コードベースが大きく変化する場合は、この値を少し下げて、メモリの「無駄」を減らします。.
opcache.force_restart_timeout: 再起動が必要であるがプロセスがまだアクティブな場合、OPcache が強制再起動を実行するまでの時間（秒単位）。これにより、非常に長い待機状態が回避されます。.
opcache.file_update_protection: 変更されたばかりのファイルがすぐにキャッシュされない保護期間（秒単位）。デプロイ中やネットワークドライブ上で、書きかけのファイルが発生するのを防ぎます。.
opcache.restrict_api: opcache_reset() およびステータス関数を呼び出すことができるスクリプトを制限します。本番環境では、管理エンドポイントのみがアクセスできるように、これを厳格に設定しています。.
opcache.blacklist_filename: キャッシュから除外するパターン（例：高度に動的なジェネレータ）を管理しているファイル。これにより、より重要なスクリプトのためのスペースを節約できます。.
opcache.validate_permission および opcache.validate_root: 複数のユーザー/chroot が関与している場合に有効です。これにより、PHP は、あるコンテキストでキャッシュされたコードが別のコンテキストで不正に使用されるのを防ぎます。.
opcache.use_cwd および opcache.revalidate_path: 異なる作業ディレクトリ/シンボリックリンクを介してパスが組み込まれる場合、OPcache がスクリプトを識別する方法を制御します。リリースシンボリックリンクでは、二重キャッシュを回避するために、これらの値を意図的にテストしています。.
opcache.cache_id: 複数の仮想ホストが同じ SHM を共有している場合（まれ）、一意の ID を使用してキャッシュを明確に分離します。.
opcache.optimization_level: 通常、デフォルトのままにしておきます。デバッグのエッジケースの場合にのみ、最適化パスを一時的に減らします。.

プリローディング：コードの一部をメモリに永続的に保持する

PHP 7.4 以降では、opcache.preload および opcache.preload_user を使用して、サーバーの起動時に中央のフレームワークファイルやプロジェクトファイルをロードしてリンクすることができます。その利点としては、クラスがオートロードヒットなしで利用可能になり、ホットパスがすぐに利用可能になることが挙げられます。いくつかの実践的なルールをご紹介します。

プリロードは、大規模で安定したコードベース（Symfony、独自のコアライブラリなど）で特に有効です。WordPress では、コア/プラグインが頻繁に更新されるため、プリロードの使用は控えめにしています。.
プリロードファイルには、特定の opcache_compile_file() コールが含まれているか、定義されたクラスをバインドするオートローダーが組み込まれています。 前もって ロード中。.
プリロードに関連するファイルにコード変更を加える場合は、プリロードを再構築するために PHP-FPM を再起動する必要があります。私はこれをデプロイメントに組み込んでいます。.
私はその効果を個別に測定しています。すべてのコードが恩恵を受けるわけではないからです。プリロードは共有メモリを追加で消費します。.

JIT と OPcache：メリット、制限、メモリ要件

PHP 8 以降、OPcache によって制御されるジャストインタイムコンパイラ (JIT) が導入されました (opcache.jit、opcache.jit_buffer_size)。I/O およびデータベースの負荷がかかる一般的な Web ワークロードでは、JIT の効果はあまり見られません。CPU 負荷の高いコード (画像/データ処理など) では、JIT が顕著な効果を発揮します。私は次のように対応しています。

JIT を保守的に有効化し、実際のユーザーメトリクスと CPU プロファイルを測定します。無差別に有効化すると、メモリ要件が増大し、エッジケースが発生する可能性があります。.
JITバッファのサイズは、CPU負荷の高いルートに応じて決定します。小さすぎるバッファは付加価値をもたらさず、大きすぎるバッファはバイトコードを圧迫します。.
ヒット率や SHM の使用率が低下している場合は、JIT より OPcache を優先します。バイトコードキャッシュは、ほとんどのサイトにとってより重要な要素です。.

ファイルパス、シンボリックリンク、安全なデプロイ戦略

OPcache はパスベースです。そのため、デプロイ戦略に焦点を当てます。

シンボリックリンクによるアトミックリリース（例：/releases/123 -> /current）：クリーンですが、opcache.use_cwd および realpath の動作に注意してください。すべてのワーカーが常に同じ実際のパスを参照するようにすることで、キャッシュの重複を回避しています。.
validate_timestamps=0 の場合、キャッシュは どこでも 空にする：切り替え後、すべてのホスト/ポッドで OPcache を意図的にフラッシュし、PHP-FPM を制御して再起動します。.
realpath_cache_size および realpath_cache_ttl は、ファイル検索が高速かつ安定的に行えるよう、OPcache と調整しています。.
ネットワークドライブ（NFS/SMB）では、file_update_protection を増やし、ファイルがアトミックに置換されるようにデプロイメントを設定しています。.

非常に高速な再起動のために、私はよく2段階の手順を採用しています。まずバックグラウンドでウォームアップを行い、次にすべてのワーカーを短時間で調整してリロードし、最初のライブトラフィックがすでにウォームアップされたキャッシュを見つけるようにします。.

ファイルキャッシュ、ウォームアップ、プライミング

共有メモリに加えて、OPcache はオプションでバイトコードをディスクに書き込むことができます (opcache.file_cache)。これは、特定のシナリオで役立ちます。

コンテナ環境では、ファイルキャッシュが間 FPMの再起動は、ストレージが高速であれば、再コンパイル時間を短縮します。.
私は opcache.file_cache を慎重に使用しています。低速または分散ファイルシステムでは、その効果はほとんどなく、複雑さを増すだけだからです。.
opcache.file_cache_only は、SHM がない環境向けの特別なケースで、パフォーマンス設定ではあまり使われないよ。.

ウォームアップのために、小さな「プライマー」を作っています。

CLI スクリプトは、オートローダー、コアフレームワーククラス、大規模なヘルパーなど、ホットファイルに対して opcache_compile_file() を呼び出します。.
クローラーは、バイトコードと下流のキャッシュが適時にウォームアップされるように、トップルート（ホームページ、ログイン、チェックアウト）を訪問します。.
バージョン切り替えの直前にウォームアップが終了するよう、タイミングを調整しています。.

スタック内のOPcache：PHP-FPM、オブジェクトキャッシュ、ページキャッシュ

OPcache は、PHP-FPM、クリーンなプロセス構成、追加のキャッシュレイヤーと組み合わせた場合にその真価を発揮します。WordPress では、データベースとレンダリングの負荷を軽減するために、オブジェクトキャッシュ（Redis など）およびページキャッシュと組み合わせて使用しています。その際、以下の点に注意しています。シングルスレッドパフォーマンス, PHPリクエストは個々のCPUコアに大きく依存しているためです。それでも負荷がかかる場合は、OPcacheの共有メモリを小さく設定しすぎないように、PHP-FPMワーカーに負荷を分散します。このようにして、 スタック 調整ネジを1つ回すだけでなく、全体的に調整する。.

頻繁なエラーと迅速なチェック

キャッシュが小さすぎると、OPcache ステータスや phpinfo() で確認できるエヴィクションが発生します。これが発生した場合、opcache.memory_consumption を段階的に増やし、ヒット率で効果を確認します。ファイルの高速化が進まない場合は、opcache.max_accelerated_files をプロジェクト内の実際のファイル数よりも高く設定します。デプロイの問題がある場合は、validate_timestamps をチェックします。0 の場合、キャッシュを明示的にクリアするまで、古いバイトコードが有効のままになります。Doctrine などのツールは DocBlock を必要とするため、save_comments=1 を設定して、 エラー 注釈がないことで回避できる。.

OPcache の監視と解釈

ヒット率を測定し、クエリがほぼ常にキャッシュから開始されるように、常に 100% に近い値を目指しています。さらに、メモリ使用率とエヴィクションの数を監視して、ボトルネックを早期に発見しています。opcache_get_status() を使って小さなダッシュボードを作成したり、既存のモニタリングソリューションに情報を入力したりしています。これにより、リリースやプラグインの更新後の変化をすぐにトレンドで確認できます。これらの指標を使って、情報に基づいた判断を下しています。決断そして、本当に必要なものだけ調整してください。.

実績のある具体的なガイドライン：

ヒット率 > 99 %、通常負荷およびピーク負荷下。それ以下では、ファイル分散とウォームアップを確認します。.
SHM の空き容量が 5～10 % 以上で安定している。そうでない場合は、メモリをスケーリングします。.
時間の経過に伴うエヴィクション：デプロイ後の1回限りの急上昇は問題ありませんが、継続的なエヴィクションは、サイズ不足または深刻な断片化を示しています。.
無駄なメモリを監視する：それが限界に達したら、制御された OPcache の再構築（たとえば、メンテナンスウィンドウ内）を計画します。.

例：トラフィックの多い WordPress セットアップ

大規模な WordPress ウェブサイトでは、CLI ワーカーも恩恵を受けられるように、opcache.enable=1 および opcache.enable_cli=1 を選択します。多くのプラグインや機能豊富なテーマが使用されている場合は、共有メモリを 384 MB 以上に設定することをお勧めします。多くのクラス名や関数名がすべてのリクエストで繰り返し使用されるため、opcache.interned_strings_buffer は 64 MB に増やします。非常にパフォーマンスの高い環境では、validate_timestamps=0 および revalidate_freq=0 を設定しますが、リリース後は毎回キャッシュを直ちにフラッシュします。重要なのは、古い バイトコード 流通し続ける。.

チューニングとデプロイメントの実践的なワークフロー

私は決まったサイクルで作業してるよ：測定、変更、チェック。まず、ヒット率、占有率、エヴィクションなどのステータス値を保存してから、パラメータを調整して、もう一度測定するんだ。リリース前には、タイムスタンプを無効にして、PHP-FPMの再起動または小さなスクリプトを使用して、OPcacheを意図的に削除します。その後、実際のトラフィックまたは代表的なベンチマークを使用して、負荷のピークを制御します。異常な動作が発生した場合は、以下も確認します。メモリの断片化, なぜなら、それらは利用可能な共有記憶力を低下させる。.

チームで実績のある追加のルーチンをいくつかご紹介します。

パラメータの変更をバージョン管理する：opcache.ini をリポジトリに追加し、プルリクエストと変更履歴で変更を反映する。.
Canaryデプロイ：まず一部のワーカー/ポッドが新しいバージョンをロードしてキャッシュを構築し、その後すべてのインスタンスにロールアウトします。.
緊急スイッチ：安全なアクセスが可能な内部管理エンドポイントで、opcache_reset() および特定の opcache_invalidate() 呼び出しを許可します。opcache.restrict_api と組み合わせて使用します。.
規模の見積もり：大まかな目安として、最初は 100～200 個の PHP ファイルごとに 1～2 MB の OPcache を計算し、実際の測定値に基づいて調整します。プラグインの多い WordPress の場合は、バッファを追加します。.

簡単にまとめると

OPcache は、コンパイルされた バイトコード RAM に保持します。メモリ、ファイル数、タイムスタンプ戦略に適切な設定を行うことで、常に短い応答時間を実現できます。PHP-FPM やその他のキャッシュ層との調整に注意して、スタック全体が適切に連携するようにしてください。ヒット率、占有率、エヴィクションを監視して、的を絞った調整を行ってください。これにより、パフォーマンスと信頼性を確保できます。 プラットフォーム 高負荷と成長に対応。.