Как я могу зафиксировать возвращение PHP 503 Ошибки на моем Apache-mod_proxy_fcgi-PHP-FPM Сервере?
я испытываю затруднения из-за своей установки php-fpm. Возможно, парни можно указать на меня в правильном направлении. Прежде всего все хорошо работает. Но время от времени, я получу 503 Ошибки. Тех ошибок не стало, после того как я перезагружаю веб-сайт. Они только когда-либо появляются на php сайтах и не изолируются к одному домену или одной платформе. Я получаю эти 503 ошибки в PHPmyAdmin, Wordpress и Typo3. Это - эти 3 сайта, которые я протестировал. Они идут отдельный vhosts и имеют различные пулы php-fpm, но они совместно используют тот же php-fpm основной prozess.
Сервер, который я выполняю, является Apache 2.4 (Рабочие MPM-события) без mod_php или cgi/fastcgi. Вместо этого я использую mod_proxy и mod_proxy_fcgi для передачи каждого .php файла моему процессу php-fpm. Одна вещь отметить, сервер еще не работает, таким образом, нет мало ни к какому трафику вообще. Серверное оборудование сильно, 12 VCores und 32 ГБ Ram.
Мой 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 в директиве Прокси прежде, и это, казалось, производило 503 ошибки чаще. Теперь, когда я удалил max=10, это, кажется, происходит меньше. Могло бы просто быть совпадение все же.
Моя Конфигурация Пула PHP-FPM (соответствующие части):
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 (соответствующие части):
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
Фактическое сообщение об ошибке из апачского 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. Но разве это не плохо к deactive UDS, мудрая производительность? Я могу настроить что-нибудь там?
- mod_proxy или mod_proxy_fcgi, не работающий правильно с php-fpm или не настроенный правильно?
- APC или ZendOPCache или Memcached, портящий вещи? Я не сказал бы, что это - Память, выделенная им, потому что существует едва что-либо продолжающееся на сервере и существует много свободной памяти
- Некоторые проблемы с конфигурацией php.ini?
- Некоторые проблемы с конфигурацией php-fpm или php-fpm объединяют конфигурацию?
Я не экспорт на тех вещах, таким образом, мне нелегко понимать вещи. Apache с php-fpm не кажется, что распространенный также, большинством результатов Google является базирующийся nginx, который не помогает мне очень.
Возможно, кто-то здесь может помочь мне?
Большое спасибо!!
Правильно ли listen = var / run / php5-fpm-mywebsite.sock ?
Что касается случая виртуального хоста, вы можете попробовать следующую конфигурацию:
Apache (в теге
VirtualHost)ProxyPassMatch ^ / (. * \. Php (/.*)?)$ fcgi: //127.0.0.1: 9000 / DOCUMENT_ROOT_OF_VHOST / $ 1Пул PHP-FPM
listen = 127.0.0.1:9000
Если вас не беспокоит .htaccess , рекомендуется nginx .
Удалите параметр enablereuse = on в строке прокси, чтобы он читался как
<Proxy fcgi://mywebsite/ retry=0>
. Это решило для меня проблему «Ошибка отправки запроса на :, referer ...».
Как было предложено в других сообщениях, enablereuse = on не следует использовать, когда демон PHP-FPM работает через сокет Unix.
Документация Apache для mod_proxy_fcgi подтверждает это, говоря:
UDS в настоящее время не поддерживает повторное использование соединения.
UDS означает сокеты домена Unix, что означает, когда вы запускаете PHP-FPM как сокет (.sock) вместо метода порта TCP по умолчанию.
Натан Захари подробно описывает настройку Apache + PHP-FPM в качестве сокета и другие связанные темы.
Я испытал сумасшедшие, непредсказуемые ответы Apache сразу после выполнения POST с enablereuse = on и UDS. Как только я удалил enablereuse = on и перезапустил службы, проблема полностью исчезла.
Подробнее о симптомах и отладке этой проблемы от людей mod_h2 .
У меня была точно такая же проблема, и после попытки понять, в чем была причина, я обнаружил, что для нас причиной был баг с плагином.
В частности, мы исправили проблему с помощью отключение этого плагина 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);
Удачи!