Вопросы Теги

Событие Apache 2.4 MPM + php-fpm + php-opcache приводит “К соединению, сброшенному одноранговым узлом” ошибки

У меня есть сервер CentOS 7 рабочий Apache 2.4.6 с Событием MPM и php-fpm версия 5.6.10 (от REMI repo). Вот соответствующая конфигурация Apache для отправления запросов к php-fpm в vhost (это - единственный сайт на этом сервере):

<FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php-fpm/www.sock|fcgi://localhost"
</FilesMatch>

Вот соответствующий пул php-fpm conf:

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 Сервисах Недоступная ошибка относительно frontend каждый раз, когда это происходит.

Я буквально провел по крайней мере 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).

У кого-либо есть какие-либо идеи, что я уже не упомянул?

1
задан 13 April 2017 в 15:14
1 ответ

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

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

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

Это, очевидно, серьезная проблема безопасности, и даже если никто не воспользуется этим, все равно существует вероятность того, что скрипты будут прочитаны неправильным пользователем при создании страницу, поэтому веб-сайты могут отображать неправильные данные / информацию, если в кеше есть несколько скриптов index.php.

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

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

ВАЖНЫЕ ПРИМЕЧАНИЯ

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

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

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

  1. Если вы запускаете приложение, работающее на 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, оставьте комментарий, чтобы сообщить нам, как вы справились с этой частью конфигурации! См. Также этот вопрос и связанные с ним комментарии .

1
ответ дан 4 December 2019 в 00:05

Теги

Похожие вопросы