2015-12-01 4 views
3

Я запускаю веб-приложение Django с помощью Nginx и uWSGI. У меня проблемы с запросами, висящими без видимых причин.Django + uWSGI + запросы nginx зависают

Я добавил в журнал пучок протоколирования, и этот фрагмент находится там, где он, кажется, висит. В начале блока try есть две строки журнала, а первая печатается, но не вторая, поэтому кажется, что она висит в середине кода. Этот код из класса промежуточного программного обеспечения, который я добавил в конфигурации Django.

def process_request(self, request): 
    if 'auth' not in request.session: 
     try: 
      log.info("Auth not found") # this line is logged 
      log.info("another log line") # this line is never logged 
      if request.is_ajax(): 
       return HttpResponse(status=401) 
      ... 

мне удалось получить трассировку из потока uWSGI и это, где он застрял:

*** backtrace of 76 *** 
/usr/bin/uwsgi(uwsgi_backtrace+0x2e) [0x45121e] 
/usr/bin/uwsgi(what_i_am_doing+0x30) [0x451350] 
/lib/x86_64-linux-gnu/libc.so.6(+0x36c30) [0x7f8a4b2b8c30] 
/lib/x86_64-linux-gnu/libc.so.6(epoll_wait+0x33) [0x7f8a4b37d653] 
/home/vdr/vdr-ui/env/local/lib/python2.7/site-packages/gevent/core.so(+0x27625) [0x7f8a44092625] 
/home/vdr/vdr-ui/env/local/lib/python2.7/site-packages/gevent/core.so(ev_run+0x29b) [0x7f8a4409d11b] 
/home/vdr/vdr-ui/env/local/lib/python2.7/site-packages/gevent/core.so(+0x32bc0) [0x7f8a4409dbc0] 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4bd4) [0x7f8a4a0c30d4] 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x80d) [0x7f8a4a0c517d] 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x162310) [0x7f8a4a0c5310] 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7f8a4a08ce23] 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x7d30d) [0x7f8a49fe030d] 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7f8a4a08ce23] 
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x7f8a4a04b837] 
/home/vdr/vdr-ui/env/local/lib/python2.7/site-packages/greenlet.so(+0x375c) [0x7f8a49b1c75c] 
/home/vdr/vdr-ui/env/local/lib/python2.7/site-packages/greenlet.so(+0x30a6) [0x7f8a49b1c0a6] 
[0x7f8a42f26f38] 
*** end of backtrace *** 
SIGUSR2: --- uWSGI worker 3 (pid: 76) is managing request /login?next=/&token=45092ca6-c1a0-4c23-9d44-4d171fc561b8 since Wed Dec 2 09:52:44 2015 --- 

начинает печать журнала ошибок Nginx из [error] 619#0: *55 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.17.0.1, server: vdr

Там нет ошибки в распечатках из uWSGI, так что я немного не понимаю. Кто-нибудь видел что-то подобное? Все это работает в контейнере Docker, если это имеет значение.

Nginx конф:

upstream uwsgi { 
    server unix:///tmp/vdr.sock; 
} 

server { 
    listen 80; 
    charset utf-8; 
    client_max_body_size 500M; 
    server_name localhost 172.17.0.2; 

    location /static { 
     alias /home/vdr/vdr-ui/static; 
    } 
    location/{ 
     include uwsgi_params; 
     uwsgi_pass uwsgi; 
     uwsgi_read_timeout 200s; 
    } 
} 

uWSGI конф:

[uwsgi] 

chdir = %d 
module = alft_ui.wsgi:application 
uid=1000 
master=true 
pidfile=/tmp/vdr.pid 
vacuum=true 
max-requests=5000 
processes=4 
env=DJANGO_SETTINGS_MODULE=alft_ui.settings.prod-live 
home=/home/vdr/vdr-ui/env 
socket=/tmp/vdr.sock 
chmod-socket=666 
+0

Может быть, это может помочь: http://stackoverflow.com/questions/18847654/nginx-uwsgi-django-and-upstream-timed- out-on-get-post – Adrian

+0

@ Adrian thanks, я попробовал некоторые предложения от этого thtread, но, к сожалению, ничего не помогло. – Petter

ответ

1

Так что я наконец-то нашел причину для этого. Оказывается, мой скрипт настройки добавил некоторые настройки logstash в конфигурацию Django. Эти настройки указывали на IP 10.8.0.1, который не был доступен из этой среды. Это объясняет, почему приложение застряло на каротажной линии. Удаление этих настроек заставило все работать снова.

Всегда хорошо знать, что это была ваша собственная вина все вместе :)

Смежные вопросы