当uWSGI需要很长时间来处理请求时,Nginx超时

时间:2013-04-22 07:28:03

标签: nginx configuration uwsgi connection-timeout

我有Python Django应用程序的Nginx + uWSGI。

我的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错误日志中会出现超时错误,如下所示:

  

2013/04/22 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分钟,有人可以告诉我我能做些什么来克服这个问题吗?

4 个答案:

答案 0 :(得分:60)

解决问题的配置是:

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

问题中的上述配置对我们不起作用的原因是因为遗憾的是在我们的机器中多个路径都有nginx.conf个文件。我们正在以错误的方式处理conf。

要正确找出你的nginx从run:

获取配置的路径
nginx -V  # V is caps

这将有一个--conf-path=[],它将准确地告诉您从哪里获取配置。

我最近发现以上nginx -V没有提供正确的信息。我会留下上述内容,以防万一其他人发现它有用。

答案 1 :(得分:2)

通过更改以下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

答案 2 :(得分:0)

除了" 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... 

答案 3 :(得分:0)

查看uwsgi错误日志并了解问题所在对我有帮助。问题根本与Nginx配置无关。我的电子邮件主机已更改,并且在调用发送电子邮件代码时代码抛出错误