ファイル更新の検出における opcache の落とし穴.bd sapi キャッシュの中国語訳はキャッシュです。

data-id="1190000004975909" data-licence="">

昨夜、オンライン障害が発生しましたが、緊急処理を行って障害復旧に切り替えた後、障害を解決し、障害から正式サービスに切り替えた後、障害は軽減されました。リカバリを実行したところ、PHP ファイルの更新が有効になる前に FPM を再起動した後、無効であることが判明しました。検討と調査のプロセスは以下に記録されます。

PHP ファイルの更新が反映されなかったため、すぐに opcache を疑い、オンラインで php.ini を確認したところ、確かに opcache が使用されており、検出間隔が 60 秒に設定されていることがわかりました。昨夜のログを見ると、更新が有効になっていない時間が 60 秒よりもはるかに長いため、この検出間隔の問題は回避でき、続行します。

オンライン環境で更新されたファイルとログの時間を確認したところ、PHPファイルの時間がログの時間と一致していないことに気づき、すぐにOPに確認を求めました。 mv からロールバックされたため、ファイルの時間が予想外でした。 stat コマンドを使用して調べたところ、確かに、変更時刻はアクセス時刻よりも少し前でした。この手がかりに基づいて、opcache は PHP ファイルの変更時刻を検出条件として使用していると推測しました。変更するファイル。問題はオフラインで再現され、ピットは正常に埋められました。

以下は、充填プロセス中にチェックされたいくつかの関連する知識ポイントを要約しています

opcache のロード

php.ini に opcache を追加するときは、拡張子の代わりに zend_extension を使用する必要があります。そうしないと、次の警告が表示されます

<code>PHP Warning:  PHP Startup: Invalid library (appears to be a Zend Extension, try loading using zend_extension=opcache.so from php.ini) in Unknown on line 0</code>

Configure opcache

パフォーマンスを向上させるには、次の推奨設定を使用してください:

<code>opcache.memory_c
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1</code>

今回は 2 つのパラメータが関係しています

revalidate_freq、デフォルトは 2 です
スクリプトのタイムスタンプが更新されたかどうかを確認する期間 (秒単位)。 これを 0 に設定すると、OPcache はリクエストごとにスクリプトの更新をチェックします

validate_timestamps、デフォルトは 1 です
有効にすると、OPcache は opcache.revalidate_freq で設定された秒ごとにスクリプトが更新されるかどうかをチェックします。 このオプションが無効になっている場合は、opcache_reset() 関数または opcache_invalidate() 関数を使用して OPcache を手動でリセットするか、ファイル システムの変更を有効にするために Web サーバーを再起動する必要があります。

システムコマンドと関数stat

アクセス時間はファイルに最後にアクセスした時間を表します
変更時間はファイルを最後に変更した時間を表します
変更時間はアクセス許可、サイズ、属性を含むファイル属性を最後に変更した時間を表します待機

C/C++ の stat メソッドを使用して、ファイルの 3 つの時間属性をクエリすることもできます。一般に、アプリケーションはファイルが更新されたかどうかを判断するために変更時間を使用します。ファイルは mv によって操作され、変更時刻は更新されないため、opcache は更新されません。

上記では、キャッシュの側面を含め、opcache によるファイル更新の検出に関する小さな落とし穴を紹介しましたが、PHP チュートリアルに興味のある友人にとって役立つことを願っています。