Nginx 正在向 uWSGI 发出非常旧的请求？

Question

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

我的设置

我的服务器使用 Nginx 通过 Unix 文件套接字将 HTTPS POST 请求传递给 uWSGI 和 Flask。我基本上对所有内容都有默认配置。

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

问题

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

我关闭了客户端。但是在关闭客户端电源后大约 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)

Nginxerror.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 在每个请求上都会给出相同的“写入关闭的管道”错误，就好像它以某种方式永久损坏一样。重新启动网络服务器的 docker 容器并不能解决问题，但重新启动主机可以解决问题。

理论

在默认的Nginx -> socket -> uWSGI配置中，是否有一个很长的请求队列，没有超时？我查看了 uWSGI 文档，看到了一堆可配置的超时，但都默认为 60 秒左右，所以我无法理解如何处理 10 分钟前的请求。我没有更改任何默认超时设置。

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

不管怎样，我想更改我的配置，以便超过 30 秒的请求会因 500 错误而被丢弃，而不是由 uWSGI 处理。我很感激任何有关如何做到这一点的建议以及有关正在发生的事情的理论。

Answer 1

这似乎是 uWSGI 下游的一个问题。

听起来您的后端代码可能有问题，因为处理请求花费的时间太长，没有对请求实现任何类型的速率限制，并且无法正确捕获任何底层连接是否已终止（因此，您正在接收代码尝试写入关闭管道的错误，甚至可能在底层连接终止很久之后才开始处理新请求）。

• 根据http://lists.unbit.it/pipermail/uwsgi/2013-February/005362.html，您可能希望中止后端内的处理if not uwsgi.is_connected(uwsgi.connection_fd())。

• 您可能想探索https://uwsgi-docs.readthedocs.io/en/latest/Options.html#harakiri。

• 作为最后的手段，根据Re: Understanding "proxy_ignore_client_abort" function (2014)，您可能希望uwsgi_ignore_client_abort从更改off为on，以便不删除已经传递到上游的正在进行的 uWSGI 连接（即使客户端随后断开连接）为了不接收来自uWSGI的关闭管道错误，以及在nginx本身内强制执行任何可能的并发连接限制（否则，如果客户端断开连接，与uWSGI的连接将被nginx丢弃，并且nginx将不知道有多少个请求正在 uWSGI 中排队以进行后续处理）。