Таймауты Nginx, когда uWSGI долго обрабатывает запрос

У меня есть приложение Nginx + uWSGI для Python Django.

У меня в nginx.conf есть следующее:

location / {
    include uwsgi_params;
    uwsgi_pass   127.0.0.1:9001;
    uwsgi_read_timeout 1800;
    uwsgi_send_timeout 300;
    client_header_timeout 300;
    proxy_read_timeout 300;
    index  index.html index.htm;
}

но для длительных запросов на uWSGI, выполнение которых занимает около 1 минуты, я получаю ошибку тайм-аута в журнале ошибок Nginx, как показано ниже:

22.04.2013 12:35:56 [ошибка] 2709 # 0: * 1 тайм-аут восходящего потока (110: тайм-аут соединения) при чтении заголовка ответа из восходящего потока, клиент: xx.xx.xx.xx, сервер:, запрос : "GET / entity / datasenders / HTTP / 1.1", восходящий поток: "uwsgi: //127.0.0.1: 9001", хост: "xxx.xx.xx.x"

Я уже установил тайм-аут заголовка и таймауты отправки / чтения uWSGI на 5 минут, может кто-нибудь, пожалуйста, скажите мне, что я могу сделать, чтобы преодолеть это?


nginx configuration uwsgi connection-timeout
person anishek    schedule 22.04.2013    source источник

Ответы (4)


arrow_upward
76
arrow_downward

Конфигурация, которая решает проблему:

location / {
    include uwsgi_params;
    uwsgi_pass   127.0.0.1:9001;
    uwsgi_read_timeout 300;
    index  index.html index.htm;
}

Причина, по которой указанная выше конфигурация в вопросе не сработала для нас, потому что, к сожалению, на нашем компьютере несколько путей имели nginx.conf файл. Мы работали с conf по неправильному пути.

Чтобы правильно определить, по какому пути ваш nginx забирает конфигурацию из запуска:

nginx -V  # V is caps

у этого будет --conf-path=[], который точно скажет вам, откуда он берет конфигурацию.

Недавно я обнаружил, что указанное выше nginx -V не дает правильной информации. Я оставлю это на всякий случай, если другие сочтут это полезным.

person anishek    schedule 22.04.2013
comment
что представляет это число? секунды? и будет ли проблема, если у нас будет большое число, например 2000? - person senaps; 11.09.2017

arrow_upward
4
arrow_downward

Решено путем изменения следующей конфигурации Nginx

proxy_connect_timeout 300;
proxy_read_timeout    300;


client_body_timeout   300;
client_header_timeout 300;
keepalive_timeout     300;

И настройка UWSGI

http-timeout = 300 // or 'socket-timeout = 300' depending on uwsgi setting
person vinayak hegde    schedule 01.09.2020

arrow_upward
0
arrow_downward

В дополнение к ответу «uwsgi_read_timeout» вы также должны проверить правильность владения вашим каталогом кеша nginx uwsgi. Право собственности должно быть установлено для того же пользователя, что и запущенный процесс nginx ... В моем случае мне пришлось это сделать

grep '^user' /etc/nginx/nginx.conf
ls -lah /var/cache/nginx/uwsgi_temp
for f in $( find /var/cache/nginx/uwsgi_temp ); do ls -lah $f; done

Эти файлы принадлежат одному и тому же пользователю? Если нет, вы можете закрыть nginx и удалить все файлы кеша, убедитесь, что правильный владелец находится в / var / cache / nginx / uwsgi_temp, и перезапустите. Возможно, вы также могли бы просто выполнить рекурсивный chown, я не тестировал этот подход.

# store the user
THEUSER=$(grep '^user' /etc/nginx/nginx.conf | sed 's/.* //; s/;.*//' )

Удалите кеш и перезапустите подход

/etc/init.d/nginx stop
rm -rf /var/cache/nginx/uwsgi_temp/* 
chown $THEUSER:$THEUSER /var/cache/nginx/uwsgi_temp
/etc/init.d/nginx start

Рекурсивный подход chown

chown -R $THEUSER:$THEGROUP /var/cache/nginx/uwsgi_temp/
# not sure if you have to restart nginx here...
person rideswitch    schedule 16.02.2015

arrow_upward
0
arrow_downward

Просмотр журналов ошибок uwsgi и понимание того, в чем проблема, мне помогли. Проблема вообще не была связана с конфигурациями Nginx. Мой почтовый хост изменился, и код вызывал ошибку при вызове кода отправки электронной почты

person Lina T    schedule 31.12.2019