У меня есть сервер, который работал нормально до 3 октября 2013 года в 10:50, когда он начал периодически возвращать клиенту ошибки «502 Bad Gateway».
Примерно 4 из 5 запросов браузера выполняются успешно, но примерно 1 из 5 не выполняется с ошибкой 502.
Журнал ошибок nginx содержит сотни таких ошибок;
2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"
Однако журнал ошибок PHP не содержит ошибок сопоставления.
Есть ли способ получить от PHP дополнительную информацию о том, почему он сбрасывает соединение?
Это nginx.conf;
user www-data;
worker_processes 4;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
access_log /var/log/nginx/access.log;
sendfile on;
keepalive_timeout 30;
tcp_nodelay on;
client_max_body_size 100m;
gzip on;
gzip_types text/plain application/xml text/javascript application/x-javascript text/css;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
include /gvol/sites/*/nginx.conf;
}
И это .conf для этого сайта;
server {
server_name www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
root /gvol/sites/bec/www/;
index index.php index.html;
location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 2592000; # 30 days
log_not_found off;
}
## Trigger client to download instead of display '.xml' files.
location ~ \.xml$ {
add_header Content-disposition "attachment; filename=$1";
}
location ~ \.php$ {
fastcgi_read_timeout 3600;
include /etc/nginx/fastcgi_params;
keepalive_timeout 0;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
}
}
## bec-components.co.uk ##
server {
server_name bec-components.co.uk;
rewrite ^/(.*) http://www.bec-components.co.uk$1 permanent;
}
я всегда буду доверять, если мои веб-серверы говорят мне: 502 Bad Gateway
что это означает:
ваш fastcgi-процесс не доступен для nginx; либо замедлять, либо совсем не соответствовать. плохой шлюз означает: nginx не может fastcgi_pass к указанному ресурсу 127.0.0.1:9000; в тот очень специфический момент.
ваш исходный журнал ошибок говорит обо всем:
.
recv() failed
-> nginx failed
(104: Connection reset by peer) while reading response header from upstream,
-> no complete answer, or no answer at all
upstream: "fastcgi://127.0.0.1:9000",
-> who is he, who failed???
из моего ограниченного pov я бы предложил:
Я знаю, что эта тема устарела, но она все еще время от времени всплывает, поэтому, ища ответы в Интернете, я придумал следующие три возможности:
session.save_path = "/var/lib/php/sessions"). Это могут быть плохие разрешения, неправильное владение, плохой пользователь / группа или более непонятные / непонятные проблемы, такие как исчерпание inodes в этом каталоге (или даже полный диск!). Обычно это не оставить много дампов ядра и, возможно, даже ничего в журналах ошибок PHP.Продолжал получать и это. Решил, увеличив opcache ограничение памяти, если вы его используете (замена APC). Кажется, что PHP-FPM разрывает соединения всякий раз, когда кеш переполняется. Это также причина, по которой ответ shgnInc исправляет его на короткое время.
Так что найдите файл /etc/php5/fpm/php.ini (или эквивалент в вашем дистрибутиве) и увеличьте memory_consumption на любом уровне, который нужен вашему сайту. Отключение opcache также может работать.
[opcache]
opcache.memory_consumption = 196
Вы можете рассмотреть этот git на github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209
Я столкнулся с аналогичной ситуацией, когда я проверял журналы ошибок для моих вышестоящих серверов, они сообщали о некоторой ошибке ulimit, поэтому я увеличил это до 1000000 (как для восходящего потока, так и для nginx), и все работало нормально
В моем случае с той же проблемой я просто перезапускаю php-fpm сервис так решил.
sudo service php5-fpm restart
Или иногда эта проблема возникает из-за огромного количества запросов. По умолчанию pm.max_requests в php5-fpm может быть 100 или ниже.
Чтобы решить эту проблему, увеличьте ее ценность в зависимости от запросов вашего сайта, например 500.
И после этого вам необходимо перезапустить службу
В моем случае отключение xdebug расширение действительно помогло.
У меня была похожая проблема:
Вы подключаетесь к php-fpm через порт 9000. (fastcgi: //127.0.0.1: 9000)
Стандартная конфигурация Ubuntu на моем сервере:
/etc/php/7.0/fpm/pool.d/www.conf:
listen = /run/php/php7.0-fpm.sock
вы должны изменить это на:
listen = 0.0.0.0:9000
В моем случае я обновил свой сервер 1 1/2 месяца назад, перезаписав конфигурацию моего костома по умолчанию. После перезапуска php-fpm эта ошибка возникла с задержкой.
Для меня это было то, что серверу не хватало памяти и php-fpm был убит OOM killer. Решением было увеличить объем памяти сервера.
Для меня это было потому, что php-fpm попал в max_children предел. Журнал php-fpm для рассматриваемого пула указал мне правильное направление
Эта проблема также может возникнуть, если процесс PHP-FPM превышает лимит выделенной памяти. Когда это происходит, соединение между NGINX и PHP-FPM разрывается, и NGINX возвращает 502 Bad Gateway. Ограничение памяти процесса PHP-FPM контролируется memory_limit переменная. Это можно установить с помощью php_admin_value[memory_limit] в файле конфигурации PHP-FPM.
Важно отметить, что ограничение памяти применяется к за сценарий основание. С участием n PHP-FPM, общее использование памяти может быть до memory_limit * n. Убедитесь, что на вашем компьютере достаточно памяти!