web-dev-qa-db-ja.com

Apacheは、ドキュメントルートの変更にすぐには気づきません

Webサイトの展開には capistrano を使用し、Apacheドキュメントルートは特定のコードリリースへのシンボリックリンクです。展開手順では、展開の最終ステップとして、シンボリックリンクを古いリリースから新しいリリースに切り替えます。

WebサーバーをRHEL5.6を実行している実サーバーからUbuntu11.10を実行しているAmazonEC2仮想マシンに移行しています。新しいサーバーでは、シンボリックリンクが切り替えられたときにApacheがドキュメントルートの変更にすぐに気付かないという問題が発生しています。 1秒ほどかかる場合があります（そして数分かかるのを見たことがあると思います）。これは、Apacheがシンボリックリンクの物理パスをしばらくの間キャッシュしていたようなものです。

提供されたファイルへの変更をより迅速に「スキャン」するために私が見ることができるいくつかのApache設定を知っている人はいますか。

考え：

  • 仮想マシン上のディスクははるかに遅い（ネットワーク接続ストレージであるため）と読みました。おそらく、ファイルシステムキャッシュもどういうわけか異なった働きをしますか？もしそうなら、何かできることはありますか？
  • ウェブサイトはPHPコードを実行します。おそらくRHELとUbuntuの間にいくつかのPHP構成の違いがありますか？私はrealpath_cache_ttlをチェックしましたが、両方のサーバーがコメントアウトしています：

例えば.

; Duration of time, in seconds for which to cache realpath information for a given
; file or directory. For systems with rarely changing files, consider increasing this
; value.
; http://www.php.net/manual/en/ini.core.php#ini.realpath-cache-ttl
;realpath_cache_ttl = 120
  • APCオペコードキャッシュを使用していますが、実験による問題ではないと思います。 PHPコードは、デプロイメントごとに異なるファイルパスにあり、stat=1を保証します。
  • これは非常に興味深い同様の質問です： 294107 -しかし私には答えを提供しません。
  • 1つの解決策は、ドキュメントルートのシンボリックリンクを変更するたびにApacheをリロードすることです。別の解決策が見つからない場合は、これを行います。
apache-2.2phpamazon-ec2capistrano
4
Tom

EBSでバックアップされた画像の場合、Amazonは舞台裏でかなり積極的なキャッシュを使用して（つまり、設定は何の意味もありません）、一般的な読み取りタスクの球場でEBSのパフォーマンスを漠然と取得することに注意してください。書き込みはディスクへのコミットに時間がかかります。

<command to modify disk> && syncである程度の成功を収めました。そのため、Amazonが同期システムコールをトラップし、EBSにも同期を強制している可能性があります。あるいは、同期がプロセスを高速化するという自然な動作かもしれません（つまり、メモリ内の変更をファイルシステムにプッシュすると、すぐにEBSも起動します）。残念ながら、AmazonはEBS技術について特に発表していません。

問題が本当にApacheにある場合は、Apacheに注意を喚起するために何かをしているのかどうかを指定しません...「apachectl-k graceful」は、各ワーカースレッドに実行を終了して終了するように指示します。次に、新しいスレッドを起動して置き換えます。理論的には、コンテンツがキャッシュされていないスレッドです。 （シンボリックリンクの宛先がApacheによってキャッシュされているとは思えません。プロセスのファイル記述子テーブルにキャッシュされている可能性があります。syncで解決できるはずです。）

2
Mike