У меня есть сервер CentOS 7 под управлением Apache 2.4.6 с Event MPM и php-fpm версии 5.6.10 (из репозитория REMI). Вот соответствующая конфигурация Apache для отправки запросов на php-fpm внутри vhost (это единственный сайт на этом сервере):
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php-fpm/www.sock|fcgi://localhost"
</FilesMatch>
Вот соответствующая конфигурация пула php-fpm:
listen = /var/run/php-fpm/www.sock
listen.owner = apache
listen.group = apache
pm = static
pm.max_children = 50
pm.max_requests = 0
Вот конфигурация php-opcache (конфигурация установки по умолчанию):
zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.blacklist_filename=/etc/php.d/opcache*.blacklist
Моя проблема: Каждый раз, когда я устанавливаю и включаю php-opcache, в моем журнале ошибок начинают появляться следующие ошибки:
[Thu Jun 18 08:10:58.499871 2015] [mpm_event:debug] [pid 16546:tid 139798115227392] event.c(986): (104)Connection reset by peer: [client 157.55.39.233:15962] AH00470: network write failure in core output filter
[Thu Jun 18 08:10:58.527424 2015] [mpm_event:debug] [pid 16546:tid 139797922195200] event.c(986): (103)Software caused connection abort: [client 157.55.39.233:15990] AH00470: network write failure in core output filter
Если я удалю php-opcache, ошибки исчезнут. Пользователи сообщают об ошибке 502 Service Unavailable на веб-интерфейсе всякий раз, когда это происходит.
Я буквально потратил не менее 6 часов, пытаясь найти в Google решения. Кто-то сказал, что opcache's fastshutdown вариант был проблемой, но он отключен в конфигурации по умолчанию. Я изменил метод управления процессом php-fpm на статический без повторного использования (max_requests = 0), но это тоже ничего не изменило. Я также пробовал использовать метод прокси TCP с Apache (вместо сокетов), и это тоже не повлияло.
Я не уверен, актуально это или нет, но независимо от того, установлен ли php-opcache или нет, я получаю следующие ошибки в журнале ошибок (но с гораздо меньшей частотой, <0,5% всего трафика, что может быть отдельной темой):
[Thu Jun 18 08:32:37.223430 2015] [proxy_fcgi:error] [pid 19187:tid 140598765840128] [client 37.46.115.238:55624] AH01068: Got bogus version 10, referer: ...
[Thu Jun 18 08:32:37.223462 2015] [proxy_fcgi:error] [pid 19187:tid 140598765840128] (22)Invalid argument: [client 37.46.115.238:55624] AH01075: Error dispatching request to :, referer: ...
Эта проблема очень похожа на вот этот, хотя этот человек использует ProxyPassMatch с методом TCP, а я - нет (потому что он обходит .htaccess).
У кого-нибудь есть идеи, о которых я еще не упомянул?
Когда я видел похожие проблемы в наших средах, это, похоже, было связано с тем, что 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 приведет к конфликтам между файлами с одинаковым базовым именем.
opcache.load_comments и opcache.save_comments директивы установлены на true. Вам следует перепроверить это предложение с документацией вашего приложения / фреймворка, так как большинство из них обновили свои документы конкретными инструкциями по включению правильного использования OpCache для своих систем:Есть также параметр, который важен в инструментах и фреймворках, в которых используются аннотации. Если вы используете Doctrine, Zend Framework 2 или PHP Unit, не забудьте установить для параметров opcache.load_comments и opcache.save_comments значение true. В результате комментарии к документации из ваших файлов также будут включены в предварительно скомпилированный код, созданный OpCache. Эта настройка позволит вам работать с аннотациями без сбоев.
Если ваш проект основан на определенной платформе или веб-приложении, всегда полезно проверить документацию на наличие рекомендаций относительно конфигурации OpCache.
ВАЖНЫЕ ЗАМЕТКИ
Надеюсь, это помогло - и если вы используете cPanel, оставьте комментарий, чтобы сообщить нам, как вы справились с этой частью конфигурации! См. Также этот вопрос и связанные с ним комментарии.