Django + uWSGI + Nginx мгновенно приводит к преждевременному закрытию восходящего соединения - PullRequest
Новая
       17

Django + uWSGI + Nginx мгновенно приводит к преждевременному закрытию восходящего соединения

0 голосов
/ 22 апреля 2019

Во-первых, я прочитал, вероятно, каждый пост stackoverflow, связанный с этой темой в эти пасхальные выходные.Например, восходящее преждевременно закрытое соединение (uwsgi + nginx + django) не решает мою проблему, потому что это был плохой код, который даже не запускался через run.verserver manage.py.Большинство сообщений о тайм-аутах.Эта ошибка выдается немедленно в файл размером менее 30 КБ.Все мои тайм-ауты на Nginx и uWSGI установлены по умолчанию на 60 с.Это не проблема тайм-аута, но, возможно, проблема с кешем.

Я записываю некоторую информацию из базы данных в файл .xlsx, используя openpyxl.Когда я возвращаю файл, его размер составляет около 27 КБ, и с вероятностью 50% он не выдаст ошибку.Если он немного больше, он терпит неудачу каждый раз, если он немного меньше, то все в порядке.Все остальные веб-страницы работают нормально для сайта.Это сообщение об ошибке:

2019/04/21 20:14:52 [error] 19712#19712: *46 upstream prematurely closed connection while reading response header from upstream, client: ipaddress, server: request: "GET / HTTP/1.1", upstream: "uwsgi://unix:////var/run/uwsgi.sock:", host: "www.mysite.com"

Файл может быть успешно загружен через manage.py runserver .Он также запускается успешно, когда я запускаю uWSGI напрямую.Единственный раз, когда это не работает, это когда Nginx передает запрос в uWSQI, а затем Nginx сразу же завершает работу при получении ответа.Поэтому я просматривал документацию Nginx, пытаясь что-то найти.

Это моя установка Nginx, настройка области кэша: 

uwsgi_cache_path /var/www/my_site/public/nginx_uwsgi_temp levels=1:2 keys_zone=myzone:64m inactive=10m;

И часть виртуального хоста, с беспорядком внеудачные попытки из: http://nginx.org/en/docs/http/ngx_http_uwsgi_module.html

# Finally, send all non-media requests to the Django server.
location / {
    uwsgi_pass django;
    # the uwsgi_params file you installed
    include /home/somefolders/uwsgi_params;

    # http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout
    # Timeouts when talking to uWSGI
    # proxy_read_timeout 60s; # Default 60s
    # proxy_send_timeout 60s; # Default 60s
    # proxy_connect_timeout 60s; # Default 60s
    # Trying uwsgi protocol, within uwsgi .ini set "protocol = uwsgi"
    # http://nginx.org/en/docs/http/ngx_http_uwsgi_module.html
    uwsgi_read_timeout 60s; # Default value 60s
    uwsgi_send_timeout 60s; # Default value 60s
    # uwsgi_cache
    # uwsgi_buffering on;
    # uwsgi_buffer_size 8k;
    # uwsgi_max_temp_file_size 1024m;
    # uwsgi_temp_path /var/www/public/nginx_uwsgi_temp 1 2;
    # client cache
    uwsgi_cache myzone;
    # uwsgi_cache_revalidate on;
    # uwsgi_cache_key $uri;
    # uwsgi_cache_valid any 10m;want
    # add_header X-Cache-Status $upstream_cache_status ;
    uwsgi_buffer_size 320k;
    uwsgi_buffers 8 320k;
    uwsgi_busy_buffers_size 320k;
    uwsgi_next_upstream off;
}

Возможно, я лаю не на том дереве, но все мои попытки указывают на какую-то конфигурацию кэша Nginx.

Мне интересно, что по умолчаниюNginx устанавливается с помощью: 

uwsgi_buffers 8 4k

, что составляет около 8 * 4 = 24 КБ, примерно до точки, в которой вещи начинают разрушаться.

1 Ответ

0 голосов
/ 22 апреля 2019

Потратив на это дни, согласно закону Мёрфиса, каждый раз, после того, как я провожу время, чтобы задать вопрос, я это выясняю.В моей конфигурации uWSGI у меня было: 

[uwsgi]
limit-as = 128

Что ж, это убивало процесс, когда он становился слишком большим.Странно было вызывать тот же файл .ini uwsgi при непосредственном запуске uWSGI, но он не превышал 128 МБ, только когда Nginx вызывает его.

Flip.Удалил эту строку и все хорошо.Я продолжал задерживать вопрос, потому что знал, что это произойдет.

...