O Apache não percebe imediatamente uma alteração na raiz do documento

Question

Nós usamos capistrano para implantações de sites e nossa raiz de documentos do Apache é um link simbólico para uma versão de código específica. O procedimento de implantação alterna o link simbólico da versão antiga para a nova versão como a etapa final da implantação.

Estamos migrando nossos servidores da Web de servidores reais que executam o RHEL 5.6 para máquinas virtuais Amazon EC2 executando o Ubuntu 11.10 e os novos servidores estão sofrendo de um problema onde o Apache não percebe imediatamente a alteração no documento raiz quando o link simbólico é alternado. Pode demorar um pouco mais ou menos ( e eu acho que eu já vi isso levar alguns minutos ). É como se o Apache tivesse armazenado em cache o caminho físico do symlink por algum tempo.

Alguém sabe algumas configurações do Apache que eu poderia analisar para "varrer" as alterações nos arquivos exibidos com mais rapidez.

Pensamentos:

• Eu li que os discos em máquinas virtuais são muito mais lentos (já que são armazenados em rede). Talvez o cache do sistema de arquivos de alguma forma funcione de maneira diferente também? Em caso afirmativo, há algo que possa ser feito?
• O site executa o código PHP. Talvez haja algumas diferenças de configuração do PHP entre o RHEL e o Ubuntu? Eu verifiquei realpath_cache_ttl , mas os dois servidores comentaram:

por exemplo,

; 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

• Nós usamos o cache de opcode da APC, mas não achamos que seja o problema devido à experimentação. O código PHP está em caminhos de arquivo diferentes para cada implementação e garantimos stat=1 .
• Eis uma pergunta semelhante que é muito interessante: 294107 - mas não fornece uma resposta para mim.
• Uma solução seria recarregar o Apache sempre que modificarmos o link simbólico da raiz do documento. Eu farei isso se não conseguirmos encontrar outra solução.

Answer 1

Se for uma imagem com suporte do EBS, observe que a Amazon usa um cache muito agressivo nos bastidores (ou seja, suas configurações não significam nada) para obter um desempenho vagamente no EBS para tarefas comuns de leitura. As gravações são mais lentas no disco.

Eu tive algum sucesso com <command to modify disk> && sync . Portanto, é possível que a Amazon esteja bloqueando a chamada do sistema de sincronização e forçando o EBS a sincronizar também. Ou talvez seja o comportamento natural da sincronização que acelera o processo (ou seja, a ativação de alterações na memória no sistema de arquivos também ativa imediatamente o EBS). Infelizmente a Amazon não é particularmente próxima sobre sua tecnologia EBS.

Se o problema realmente está no Apache, você não especifica se está fazendo alguma coisa para tentar alertar o Apache para prestar atenção ... um "apachectl -k graceful" irá dizer a cada thread de trabalho para terminar o que está fazendo e sair, em seguida, lançar um novo segmento para substituí-lo, em teoria, um que não tenha o conteúdo em cache. (Eu duvido que o destino do symlink seja armazenado em cache pelo Apache, ele pode ser armazenado em cache na tabela do descritor de arquivo para o processo; sync deve resolver isso.)