У меня есть настройка сайта с Nginx как балансировщик нагрузки (less_conn), который использует отдельный сервер uwsgi/django как его восходящий поток. Обычно это пул из примерно 5 серверов uwsgi/django, но я ограничил его только одним, чтобы убедиться, что это не плохой сервер.Nginx обратный прокси uwsgi django intermittent 502
В нормальном режиме работы пользователя все работает нормально. Моя проблема заключается в том, что быстрые последовательные запросы будут периодически генерировать ошибку 502. Я могу воссоздать это с помощью нескольких попыток, открыв страницу в нашем администраторе, которая содержит список ко всем статьям. Открыв связку ссылок на новых вкладках, около 1 из 10 завершится с ошибкой 502.
Другое любопытство, 502-е случаются очень быстро, когда они происходят. Например, когда появляется 502, это мгновенно, как открытие вкладки. Где бы я ожидал, что интерфейс nginx немного подождет, прежде чем вернуться с ошибкой.
Я использую uwsgi_pass для прямого прокси между балансиром нагрузки nginx и uwsgi. Я читал в нескольких других сообщениях о необходимости увеличения буферов. Я пробовал установить uwsgi_buffers_size 16k; и uwsgi_buffers 4 16k; но они не изменили ситуацию.
Журналы ошибок от Nginx и Uwsgi ничего не показывают о 502s. Инструменты Google для веб-мастеров, однако, замечают их.
Соответствующие настройки nginx.conf:
worker_processes auto;
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;
events {
multi_accept on;
use epoll;
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log off;
sendfile on;
tcp_nopush on;
#Timeouts
keepalive_timeout 65;
send_timeout 60;
client_body_timeout 12;
client_header_timeout 12;
upstream backend {
least_conn;
server ipaddress:22882;
}
server {
listen 27313;
server_name exampledomain.com;
access_log off;
port_in_redirect off;
uwsgi_next_upstream error;
location/{
uwsgi_read_timeout 300;
uwsgi_send_timeout 150;
uwsgi_connect_timeout 300;
uwsgi_buffer_size 16k;
uwsgi_buffers 4 16k;
uwsgi_pass backend;
}
Uwsgi начал с этими параметрами:
--socket :22882
--master
--workers 5
--threads 2
--max-requests 1500
--wsgi-file ~/django_prod/wsgi.py
--pidfile ~/django_prod/nginx/log/uwsgi.pid
--daemonize ~/django_prod/nginx/log/uwsgi.log
--python-path ~/django_prod
--python-path ~/django_prod/lib/
--env DJANGO_SETTINGS_MODULE=myproject.settings
--vacuum
Обратите внимание, что ошибка 502 отличается от 504. Это не «тайм-аут шлюза», это «ошибка шлюза», поэтому настоящая причина находится на стороне django. Я предполагаю, что, когда рабочий предел превышен, django выбрасывает ошибку 502 на последующих повторителях, но я не знаю, что django достаточно хорош, чтобы быть уверенным. –
Я вижу, что, когда страница 502s, соответствующая запись в журнале UWSGI выглядит нормально, как и любой другой рабочий запрос. Я знаю, что эта запись - это страница с ошибкой 502 на основе времени и того факта, что это очень старая статья, к которой обычно не обращались. [pid: 3226 | приложение: 0 | req: 565/2827] 127.0.0.1() {68 vars в 1628 байт} [Вт 25 окт 10:55:02 2016] GET/admin/news/news/149/? _changelist_filters = p% 3D218 => сгенерировано 13862 байт за 92 мс (HTTP/1.0 200) 6 заголовков в 307 байт (1 переключатель на ядре 0) – finnthehuman