Проблемы с APC на публикации

Question

Мы недавно включили APC на наших серверах, и иногда, когда мы публикуем новый код или изменения, мы обнаруживаем, что исходные файлы, которые были изменены, начинают выдавать ошибки, которые не отражаются в коде, обычно разбирать ошибки, описывающие токен, который не существует. Мы проверили это, запустив php -l на файлах, которые, по сообщениям журналов ошибок, затрагиваются. Обычно повторная публикация устраняет проблему. Мы используем PHP 5.2.0 и APC 3.01.9. У меня вопрос, сталкивался ли кто-нибудь еще с этой проблемой, или кто-то знает, в чем наша проблема? Если так, как вы это исправили или как мы могли это исправить?

Редактировать: вероятно, мне следует добавить некоторые подробности о нашем процессе публикации. Контент передается на рабочие серверы через rsync с промежуточного сервера. Мы включили apc.stat_ctime, потому что он сказал, что это помогает работать более гладко с rsync. apc.write_lock включено по умолчанию, и мы не отключили его. То же самое для apc.file_update_protection.

Answer 1

Похоже, что частично опубликованный файл читается и кэшируется как поврежденный. apc.file_update_protection разработан, чтобы помочь остановить это.

в php.ini: apc.file_update_protection integer

apc.file_update_protection настройка задерживает кэширование файлы. По умолчанию это 2 секунды, которые означает, что если модификация отметка времени (mtime) в файле показывает, что возраст менее 2 секунд доступ к нему не будет кэшироваться. Несчастный человек, который получил доступ этот наполовину написанный файл все равно увидит странность, но, по крайней мере, это не так сохраняются.

После редактируемого вопроса: одной из причин, по которой я не вижу подобных проблем, является то, что я нажимаю на целую новую копию сайта (с экспортом SVN). Только после того, как это полностью завершено, оно становится видимым для Apache / Mod_php (см. Мой ответ Как начать развертывание приложений PHP из хранилища Subversion? )

Другая вещь, которая может произойти, конечно, это то, что, если вы обновляете на месте, вы можете обновлять файлы, которые зависят от других, которые еще не были загружены. Rsync может гарантировать атомарные обновления только для отдельных файлов, а не для всей коллекции, которая изменяется / загружается. Еще одна причина, по которой я думаю загрузить сайт в массовом порядке, и только потом вводить в действие.

Answer 2

Похоже, APC не выполняет предварительную обработку или не получает правильную информацию о состоянии файла. Вы можете проверить это, чтобы убедиться, что конфигурация APC apc.stat установлена ​​правильно. Еще одна вещь, которую вы могли бы сделать - принудительно очистить кэш с помощью apc_clear_cache () при публикации нового кода.

Answer 3

Вероятно, это происходит из-за несоответствия между вашим кодом и кэшированными версиями кода.

Например, у APC есть кэшированная версия User.php, но вы внесли изменения в User.php или в данные, которые использует пользователь. Кэшированная версия все еще работает даже после вашего развертывания, потому что срок ее действия еще не истек.

Если вы очистите записи кэша APC при развертывании, эта проблема должна исчезнуть.

Answer 4

ctime означает время создания. Вам нужно будет вручную очищать весь кэш каждый раз, когда вы делаете обновления.

Вы можете легко сделать это, разместив скрипт apc.php где-нибудь на вашем сервере. Этот скрипт предоставляет вам статистику кэша и позволит вам полностью удалить кеш.

Скрипт поставляется с APC.

Надеюсь его поможет, Эверт

Answer 5

Когда вы получаете файл с ошибкой разбора, сделайте резервную копию, а затем повторите печать. Возьмите тот же самый файл, который сейчас работает, и проведите сравнение с файлом с ошибкой разбора.

Answer 6

Никогда раньше такого не видел, даже если я большой пользователь APC. Может быть, попытаться запустить сценарий, который очищает код операции APC при каждой отправке нового кода на сервер?