Nginx给uWSGI很老的请求？

我看到一个奇怪的情况，Nginx或者uwsgi似乎正在build立一个长长的传入请求队列，并在客户端连接超时后尝试处理它们。 我想了解并制止这种行为。 以下是更多信息：

我的设置

我的服务器使用Nginx通过Unix文件套接字将HTTPS POST请求传递给uWSGI和Flask。 我基本上都是默认configuration。

我有一个Python客户端每秒发送3个请求到该服务器。

• 在Gunicorn下Flask的TemplateNotFound错误疑难解答
• Nginx和Flask-socketio Websockets：活着但不是消息？
• uWSGI有什么意义？
• X-Forwarded-Proto和Flask
• Flask 301响应

问题

运行客户端大约4小时后，客户端机器开始报告所有连接超时。 （它使用Python请求库，超时时间为7秒）大约10分钟后，行为发生了变化：连接开始失败，出现502 Bad Gateway。

我关掉了客户端。 但是在closures客户端电源大约10分钟后，服务器端uWSGI日志显示uWSGI试图回应来自该客户端的请求！ top显示uWSGI使用100％的CPU（每个工人25％）。

在这10分钟内，每个uwsgi.log条目看起来像这样：

Thu May 25 07:36:37 2017 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /api/polldata (ip 98.210.18.212) !!! Thu May 25 07:36:37 2017 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 296] during POST /api/polldata (98.210.18.212) IOError: write error [pid: 34|app: 0|req: 645/12472] 98.210.18.212 () {42 vars in 588 bytes} [Thu May 25 07:36:08 2017] POST /api/polldata => generated 0 bytes in 28345 msecs (HTTP/1.1 200) 2 headers in 0 bytes (0 switches on core 0)

而Nginx的error.log显示了很多这样的：

2017/05/25 08:10:29 [error] 36#36: *35037 connect() to unix:/srv/my_server/myproject.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 98.210.18.212, server: example.com, request: "POST /api/polldata HTTP/1.1", upstream: "uwsgi://unix:/srv/my_server/myproject.sock:", host: "example.com:5000"

大约10分钟后，uWSGI活动停止。 当我重新打开客户端时，Nginx很高兴地接受POST请求，但是uWSGI在每个请求中都给出了“写入一个closures的pipe道”的错误，就好像它永久地被破坏了一样。 重新启动Web服务器的docker容器不能解决问题，但重新启动主机修复它。

理论

在默认的Nginx – > socket – > uWSGIconfiguration中，有没有超时请求的长队列？ 我查看了uWSGI文档，看到了一些可configuration的超时时间，但是所有的默认时间都在60秒左右，所以我不明白我是如何处理10分钟的请求的。 我没有改变任何默认的超时设置。

该应用程序几乎所有的1GB RAM在我的小开发服务器，所以我认为资源限制可能会触发行为。

无论哪种方式，我想改变我的configuration，使得> 30秒的请求被删除500错误，而不是由uWSGI处理。 我会很感激有关如何做到这一点的任何build议，以及有关发生的事情的理论。