Как я могу исправить повторяющиеся ошибки PHP 503 на моем сервере Apache-mod_proxy_fcgi-PHP-FPM?

У меня проблемы с настройкой php-fpm. Может быть, вы, ребята, можете указать мне правильное направление. Во-первых, все работает нормально. Но время от времени я получаю 503 ошибки. Эти ошибки исчезли, как только я перезагрузил сайт. Они только когда-либо появляются на сайтах php и не изолированы ни от одного домена или одного фреймворка. Я получаю 503 ошибки в PHPmyAdmin, Wordpress и Typo3. Это те 3 сайта, которые я тестировал. Они находятся на отдельных vhosts и имеют разные пулы php-fpm, но у них общий процесс php-fpm.

Сервер, на котором я работаю, - это Apache 2.4 (MPM-Event Workers), без mod_php или cgi/fastcgi. Вместо этого я использую mod_proxy и mod_proxy_fcgi для передачи каждого файла.php моему процессу php-fpm. Стоит отметить, что сервер еще не запущен, поэтому трафика практически нет. Серверное оборудование сильное, 12 VCores и 32 ГБ оперативной памяти.

Мои настройки mod_proxy и mod_proxy_fcgi являются настройками по умолчанию - я ничего там не менял.

Мой конфиг vhost (часть прокси):

<FilesMatch "\.php$">
        SetHandler "proxy:unix:///opt/php-5.6.11/var/run/php5-fpm-mywebsite.sock|fcgi://mywebsite/"
    </FilesMatch>
    <Proxy fcgi://mywebsite/ enablereuse=on retry=0>
</Proxy>

Примечание: у меня было max=10 в директиве Proxy раньше, и, похоже, чаще выдает ошибку 503. Теперь, когда я удалил max=10, кажется, что происходит меньше. Может быть, просто совпадение.

Мой PHP-FPM Pool Config (соответствующие части):

listen = var/run/php5-fpm-mywebsite.sock
listen.owner = mywebsite
listen.group = www-data
listen.mode = 0660
listen.backlog = 65535

user = mywebsite
group = www-data
listen.allowed_clients = 127.0.0.1

pm = ondemand
pm.max_children = 20
pm.process_idle_timeout = 15s

request_terminate_timeout = 300s
rlimit_files = 131072
rlimit_core = unlimited
catch_workers_output = no

Мой PHP-FPM Config (соответствующие части):

emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 10
events.mechanism = epoll

Мой PHP.ini для основного процесса PHP-FPM. Все, что здесь не указано, является либо настройками php по умолчанию, либо не должно соответствовать:

memory_limit = 400M
upload_max_filesize = 20M
post_max_size = 20M
max_execution_time = 600
max_input_time  = -1
max_input_vars = 10000
suhosin.get.max_vars = 10000
suhosin.post.max_vars = 10000

[Zend]
zend_extension=/opt/php-5.6.11/lib/php/extensions/no-debug-non-zts-20131226/ioncube.so
zend_extension=opcache.so
opcache.revalidate_freq=0
;opcache.validate_timestamps=0
opcache.max_accelerated_files=50000
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1

[APC]
extension=apcu.so
apc.enabled=1
apc.shm_segments = 1
apc.shm_size=256M
apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600
apc.stat=1
apc.enable_cli=0
apc.file_update_protection=2
apc.max_file_size=2M
apc.include_once_override=0
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.cache_by_default=1
apc.use_request_time=1
apc.slam_defense=0
apc.stat_ctime=0
apc.canonicalize=1
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.lazy_classes=0
apc.lazy_functions=0

extension=memcache.so
extension=memcached.so

Примечание. Для Memcached выделено 1 ГБ памяти.

Журнал ошибок Apache

Фактическое сообщение об ошибке из apache error.log. Сообщение об ошибке, если всегда то же самое. (Я включил подробное ведение журнала прокси):

[proxy:debug] [pid 141760:tid 140526898214656] mod_proxy.c(1159): [client myclient] AH01143: Running scheme unix handler (attempt 0), referer: http://mywebsite/website/typo3/install/index.php?TYPO3_INSTALL[type]=cleanup
[proxy_fcgi:debug] [pid 141760:tid 140526898214656] mod_proxy_fcgi.c(879): [client myclient] AH01076: url: fcgi://mywebsite//var/www/html/mywebsite/htdocs/typo3site/website/index.php proxyname: (null) proxyport: 0, referer: http://mywebsite/website/typo3/install/index.php?TYPO3_INSTALL[type]=cleanup
[proxy_fcgi:debug] [pid 141760:tid 140526898214656] mod_proxy_fcgi.c(886): [client myclient] AH01078: serving URL fcgi://mywebsite//var/www/html/mywebsite/htdocs/typo3site/website/index.php, referer: http://mywebsite/website/typo3/install/index.php?TYPO3_INSTALL[type]=cleanup
[proxy:debug] [pid 141760:tid 140526898214656] proxy_util.c(2147): AH00942: FCGI: has acquired connection for (mywebsite)
[proxy:debug] [pid 141760:tid 140526898214656] proxy_util.c(2200): [client myclient] AH00944: connecting fcgi://mywebsite//var/www/html/mywebsite/htdocs/typo3site/website/index.php to mywebsite:8000, referer: http://mywebsite/website/typo3/install/index.php?TYPO3_INSTALL[type]=cleanup
[proxy:debug] [pid 141760:tid 140526898214656] proxy_util.c(2237): [client myclient] AH02545: fcgi: has determined UDS as /opt/php-5.6.11/var/run/php5-fpm-mywebsite.sock, referer: http://mywebsite/website/typo3/install/index.php?TYPO3_INSTALL[type]=cleanup
[proxy:debug] [pid 141760:tid 140526898214656] proxy_util.c(2409): [client myclient] AH00947: connected //var/www/html/mywebsite/htdocs/typo3site/website/index.php to httpd-UDS:0, referer: http://mywebsite/website/typo3/install/index.php?TYPO3_INSTALL[type]=cleanup
[proxy_fcgi:error] [pid 141760:tid 140526898214656] [client myclient] AH01067: Failed to read FastCGI header, referer: http://mywebsite/website/typo3/install/index.php?TYPO3_INSTALL[type]=cleanup
[proxy_fcgi:error] [pid 141760:tid 140526898214656] (104)Connection reset by peer: [client myclient] AH01075: Error dispatching request to : , referer: http://mywebsite/website/typo3/install/index.php?TYPO3_INSTALL[type]=cleanup
[proxy:debug] [pid 141760:tid 140526898214656] proxy_util.c(2162): AH00943: FCGI: has released connection for (mywebsite)

Теперь мой вопрос:

Как я могу исправить повторяющиеся ошибки PHP 503 на моем веб-сервере?

Мои мысли:

  • Может быть, mod_proxy_fcgi в режиме UDS. Но разве не плохо для деактивированного UDS, с точки зрения производительности? Могу ли я что-нибудь там настроить?
  • mod_proxy или mod_proxy_fcgi не работают правильно с php-fpm или неправильно настроены?
  • APC или ZendOPCache или Memcached все портят? Я бы не сказал, что им выделена память, потому что на сервере почти ничего не происходит, и есть много свободной памяти.
  • Некоторые проблемы с конфигом php.ini?
  • Некоторые проблемы с конфигурацией php-fpm или конфигурацией пула php-fpm?

Я не экспортер этих вещей, поэтому мне сложно разобраться. Apache с php-fpm тоже не слишком распространен, большинство результатов Google основаны на nginx, что мне мало помогает.

Может, кто-то здесь может мне помочь?

Большое спасибо!!

Источник

6 ответов

Удалите опцию enablereuse=on в строке Proxy, чтобы она читалась

<Proxy fcgi://mywebsite/ retry=0>

Это решило проблему "Ошибка отправки запроса на:, referer... " для меня.

Источник

У меня была точно такая же проблема, и после попытки понять, в чем причина, я обнаружил, что для нас причиной был глючный плагин.

В частности, мы устранили проблему, отключив этот плагин WordPress: https://wordpress.org/plugins/custom-css-js/

Мы использовали PHP 7 и WordPress 4.5.6.

Так что для нас не было неправильной конфигурации php, apache или какой-либо кеш-системы. Ни одна из этих проблем не была связана с отсутствием доступных ресурсов (ЦП / ОЗУ). Проблема была из-за глючного плагина.

Было очень сложно найти, какие плагины вызвали проблему. Мы поняли благодаря параметрам отладки php, поэтому я предлагаю добавить эти строки ниже в wp-config.php для отладки:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);

Удачи!

Источник

Как и предполагалось в других сообщениях, enablereuse=on не должен использоваться, когда демон PHP-FPM работает через сокет Unix.

Документация Apache для mod_proxy_fcgi подтверждает это, говоря:

UDS в настоящее время не поддерживает повторное использование соединения

UDS означает Unix Domain Sockets, что означает, что когда вы используете PHP-FPM в качестве сокета (.sock) вместо метода TCP-порта по умолчанию.

Натан Захари подробно рассказывает о настройке Apache + PHP-FPM в качестве сокета, а также о других связанных темах.

Я испытал сумасшедшие, непредсказуемые ответы Apache сразу после выполнения процедуры POST с enablereuse=on и UDS. Как только я удалил enablereuse=on и перезапустил службы, проблема полностью исчезла.

Подробнее о симптомах и отладке этой проблемы от пользователей mod_h2.

Источник

Является listen = var/run/php5-fpm-mywebsite.sock правильный?

Что касается случая виртуального хоста, вы можете попробовать эти конфигурации:

  • Апач (в VirtualHost тег)

    ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/DOCUMENT_ROOT_OF_VHOST/$1

  • PHP-FPM пул

    listen = 127.0.0.1:9000

Если у вас нет проблем с .htaccess, nginx Рекомендовано.

Источник

Мы достигли тайм-аута по умолчанию в 60 секунд. Я добавил строкуProxyTimeout 300в файл .conf в каталоге/etc/apache2/sites-enabledчтобы Apache2 дольше ждал PHP.

Проверьте, как быстро вы получаете ошибку HTTP 503. Если это произойдет в течение нескольких секунд, этот ответ не для вас.

Вы можете найти документацию здесь: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxytimeout .

Источник

У меня была подобная проблема, и я исправил ее, переместив папки из /var/lib/php/opcache/ и затем перезапустив php-fpm.

Возможно, актуально: вчера вечером пользователь рассылал спам по URL-адресу PHP, из-за чего эти ошибки повторялись в нашем журнале Apache.

      [pid 925] worker.c(1613): AH00288: scoreboard is full, not at MaxRequestWorkers

Я предполагаю, что это вызвало повреждение кеша в папке, расположенной в /var/lib/php/opcache.

По какой-то причине сброс opcache через панель управления opcache или перезапуск apache/php-fpm, похоже, очищают эти папки. Вы должны сделать это вручную.

Но, похоже, это сработало для меня.

Источник
Другие вопросы по тегам