Apache不会立即注意到文档根目录中的更改

我们使用capistrano进行网站部署,我们的Apache文档根目录是特定代码版本的符号链接。 部署过程将符号链接从旧版本切换到新版本,作为部署的最后一步。

我们正在将我们的Web服务器从运行RHEL 5.6的真实服务器迁移到运行Ubuntu 11.10的Amazon EC2虚拟机,并且新服务器遇到了一个问题:Apache在切换符号链接时没有立即注意到文档根目录的变化。 这可能需要一秒左右( 我想我已经看了几分钟 )。 这有点像Apachecaching了符号链接的物理path一段时间。

有谁知道一些Apache设置,我可以看看它来“扫描”更快的服务文件的变化。

思考:

  • 我读了虚拟机上的磁盘速度慢得多(因为它们是networking连接存储)。 也许文件系统caching不知何故工作呢? 如果是的话,有什么可以做的吗?
  • 该网站运行PHP代码。 也许RHEL和Ubuntu之间有一些PHPconfiguration的区别? 我检查了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操作码caching但不认为这是由于实验的问题。 PHP代码在每个部署中位于不同的文件path中,我们确保stat=1
  • 这是一个非常有趣的类似问题: 294107 – 但是没有为我提供答案。
  • 每当我们修改文档根目录符号链接时,一个解决scheme就是重新加载Apache。 如果我们找不到其他解决scheme,我会这样做。

如果是EBS支持的图片,请注意,Amazon使用了一些非常积极的caching(即你的设置没有任何意义)来让EBS的performance隐约出现在公共阅读任务中。 写入速度较慢,无法提交到磁盘。

我用<command to modify disk> && sync取得了一些成功。 因此,亚马逊可能会陷入同步系统调用并强制EBS同步。 或者,也许这是同步加速过程的自然行为(即立即将内存中的变化推入文件系统也会触发EBS)。 不幸的是,亚马逊并不特别关心他们的EBS技术。

如果问题确实存在于Apache中,则不要指定是否尝试提醒Apache注意…“apachectl -k graceful”会告诉每个工作线程完成正在执行的操作并退出,然后启动一个新的线程来replace它,理论上是一个没有caching的内容。 (我怀疑这个符号链接的目的地是由Apachecaching的,它可能会caching在这个进程的文件描述符表中; sync应该可以解决这个问题。)