Назад | Перейти на главную страницу

Apache не сразу замечает изменение корня документа

Мы используем капистрано для развертываний веб-сайтов, а корень нашего документа Apache - это символическая ссылка на конкретную версию кода. Процедура развертывания переключает символическую ссылку со старого выпуска на новый выпуск в качестве последнего шага развертывания.

Мы переносим наши веб-серверы с реальных серверов под управлением RHEL 5.6 на виртуальные машины Amazon EC2 под управлением Ubuntu 11.10, и новые серверы страдают от проблемы, когда Apache не сразу замечает изменение корня документа при переключении символической ссылки. Это может занять секунду или около того (и я думаю, что даже видел, как это заняло пару минут). Это похоже на то, как Apache какое-то время кэшировал физический путь символической ссылки.

Кто-нибудь знает некоторые настройки Apache, на которые я мог бы взглянуть, чтобы заставить его «сканировать» на предмет изменений в обслуживаемых файлах быстрее.

Мысли:

Я читал, что диски на виртуальных машинах много медленнее (поскольку они являются сетевыми хранилищами). Может, кеш файловой системы тоже как-то иначе работает? Если да, то что можно сделать?
На сайте работает PHP-код. Возможно, есть некоторые различия в конфигурации PHP между RHEL и Ubuntu? Я проверил 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 - но не дает мне ответа.
Одним из решений было бы перезагружать Apache каждый раз, когда мы изменяем корневую символическую ссылку документа. Я сделаю это, если мы не сможем найти другое решение.

Если это изображение с поддержкой EBS, обратите внимание, что Amazon использует довольно агрессивное закулисное кэширование (т.е. ваши настройки ничего не значат), чтобы получить производительность EBS на уровне приблизительных значений для обычных задач чтения. Запись на диск выполняется медленнее.

Я добился некоторого успеха с <command to modify disk> && sync. Так что, возможно, Amazon перехватывает системный вызов синхронизации и также заставляет EBS синхронизироваться. Или, может быть, это естественное поведение синхронизации, ускоряющее процесс (т.е. немедленное внесение изменений в память в файловую систему также приводит к сбоям в работе EBS). К сожалению, Amazon не особо раскрывает свои технологии EBS.

Если проблема действительно связана с Apache, вы не указываете, делаете ли вы что-либо, чтобы попытаться привлечь внимание Apache ... "apachectl -k graceful" скажет каждому рабочему потоку завершить то, что он делает, и выйти, затем запустите новый поток, чтобы заменить его, теоретически не кэширующий контент. (Я сомневаюсь, что место назначения символической ссылки кэшируется Apache, она может быть кэширована в таблице файловых дескрипторов для процесса; sync должен решить это.)