Ошибки при включении zend_opcache на php-fpm с прокси-сервером apache 2.4

Question

Ошибки при включении zend_opcache на php-fpm с прокси-сервером apache 2.4

Я настраиваю веб-сервер для размещения нескольких небольших сайтов (в основном WordPress), собирая php-fpm 5.5.9 и apache 2.4.10 в Ubuntu.

Прочитав большое количество руководств и постов, я решил настроить php-fpm для запуска сокета для каждого веб-сайта и использовать mod_proxy_fcgi на apache для перенаправления запросов на php-fpm.

<LocationMatch "^(.*\.php)$">
ProxyPass unix:///var/run/php5-fpm-saintsein.com.sock|fcgi://127.0.0.1:9000/home/saintsein/public_html/
</LocationMatch>

У меня все работает почти гладко, но как только я включаю Zend Opcache в конфигурации php. Я случайно получаю сообщения об ошибках на сайте.

Единственная запись в журнале, которую я получаю, это:

Connection reset by peer: [client 194.78.30.55:55202] AH01075: Error dispatching request to :

Я искал в Интернете, и я не смог найти никого с этой конкретной ошибкой в статусе Zend Opcache.

Кто-нибудь знает, что может быть не так? Или как я могу это отладить?

0

apache-2.4 php-fpm cache zend-optimizer opcode

Источник

tempo 05 янв '15 в 11:14

1 ответ

Другие вопросы по тегам apache-2.4 php-fpm cache zend-optimizer opcode

Bryan 'BJ' Hoffpauir Jr. 12 июл '15 в 14:39 2015-07-12 14:39 · Answer 1 · 2015-07-12 14:39

Когда я встречал подобные проблемы в наших средах, это происходило из-за того, что OpCache (по умолчанию) совместно использует один кэш для всех пользователей в среде общего хостинга. Была отправлена ошибка (и вы можете, и должны, пойти и проголосовать, чтобы сообщить сопровождающим, насколько это может быть важно для вашего варианта использования), хотя никаких обязательств по доставке исправления не было.

TL; DR: по умолчанию, когда включен OpCache, кеш, который используется для хранения скомпилированного байт-кода, используется всеми пользователями. В среде, где хостинг распределяется между несколькими сайтами / пользователями, это может привести к тому, что сайт получит кэшированный вывод сценариев php с другого сайта или, если определенные параметры безопасности включены, даже генерирует ошибки.

Если вы планируете использовать PHP-FPM со встроенным opcache в PHP 5.5+, пожалуйста, прочитайте блог ниже, прежде чем вы действительно это сделаете. Оказывается, что кэш кода операции может быть прочитан любым пользователем на сервере. Это означает, что если, скажем, есть 10 отдельных пользователей со своими собственными vhosts и каталогами, и вы настраиваете один пул PHP-FPM на пользователя, каждый пользователь по-прежнему может видеть, какие сценарии кэшируются и их местоположения. Так как у них есть доступ на чтение к кешу, они потенциально могут просматривать все эти данные.
Это, очевидно, серьезная проблема безопасности, и даже если никто не воспользуется этим, все равно есть вероятность, что скрипты будут прочитаны не тем пользователем при создании страницы, поэтому веб-сайты могут отображать неверные данные / информацию, если существует несколько индексов. Скрипты.php в кеше.

Хотя официально не было выпущено ни одного исправления, если вы используете cPanel, в этой вики есть документированный способ настройки пулов php-fpm, которые будут создаваться и защищаться для каждого пользователя, и если вы будете следовать приведенным ниже инструкциям, а также ВАЖНЫЕ ЗАМЕЧАНИЯ В нижней части этого ответа вы сможете получить желаемую функциональность без каких-либо ошибок

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

ВАЖНЫЕ ЗАМЕТКИ

Во время тестирования и дополнительных исследований я наткнулся на эту статью, в которой приведены некоторые пояснения, которые могут иметь отношение к вашей конкретной ситуации:

Вы должны убедиться, что opcache.use_cwd параметр установлен в true для конфигурации вашего приложения OpCache - он установлен в false по умолчанию, если оставить значение по умолчанию, это может вызвать конфликты, если в вашей системе размещено более одного приложения PHP:

Прежде всего, вероятно, в каждом типичном проекте вам нужно убедиться, что для опции opcache.use_cwd установлено значение true. Включение этого параметра означает, что механизм OpCache будет просматривать полные пути к файлам, чтобы различать файлы с одинаковыми именами. Установка его в false приведет к конфликтам между файлами с одинаковым базовым именем.

Если вы работаете с приложением, основанным на Zend Framework или другой подобной платформе, которая использует аннотации, вы также должны убедиться, что opcache.load_comments а также opcache.save_comments директивы установлены в true, Вам следует дважды проверить это предложение в документации по вашему приложению / фреймворку, поскольку большинство из них уже обновили свои документы с конкретными инструкциями по правильному использованию OpCache для своих систем:

Существует также параметр, который важен в инструментах и средах, которые используют аннотации. Если вы используете Doctrine, Zend Framework 2 или PHP Unit, не забудьте установить для параметров opcache.load_comments и opcache.save_comments значение true. В результате комментарии документации к вашим файлам также будут включены в предварительно скомпилированный код, сгенерированный OpCache. Этот параметр позволит вам работать с аннотациями без сбоев.
Если ваш проект основан на конкретной платформе или веб-приложении, всегда полезно проверить документацию на предмет каких-либо рекомендаций, касающихся конфигурации OpCache.

ВАЖНЫЕ ЗАМЕТКИ

Надеюсь, это помогло - и если вы используете cPanel, оставьте комментарий, чтобы сообщить нам, как вы справились с этой частью конфигурации! Смотрите также этот вопрос и связанные с ним комментарии.