虽然请求尚未完成，但uWSGI工作人员正在重生

Question

我基于这个tutorial编写了一个flask应用程序

我的应用程序就像一种文件分发器。它接受文件并将其分发到其他系统上的不同api。在

有时我会在nginx错误日志中看到以下错误。在

2019/11/06 14:01:01 [error] 28912#28912: *19810346 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.2.60, server: my.host.local, request: "POST /file/add HTTP/1.1", upstream: "uwsgi://unix:/var/my_project/myproject.sock:", host: "my.host.local"

我打开了uWSGI日志，观察到当uWSGI在60秒后重新启动它的工人时，nginx日志中的错误也会出现。这种情况并不总是发生，但在大多数情况下（~90%）都是这样。有时它只是工作，所以我想，这一定是时间问题或类似的问题。在

如果我的猜测是正确的，那么工作人员寿命的增加应该会减少nginx日志中错误事件的数量。实际上，uWSGI不应该在请求还没有完成的时候就让工人重生，那么问题是什么呢？在

uWSGI ini文件：

^{pr2}$

我的应用程序运行在一个Ubuntu18.04.3LTS虚拟机上，有24个CPU和128GB的RAM（我知道这可能有点过头了，但这只是为了测试）

Answer 1

由于uwsgi正在重新生成其工作人员，因此似乎触发了harakiri超时。在

harakiri模式使uwsgi重新启动工作进程如果相关响应花费的时间超过harakiri\u秒，则可以给它一个更大的超时，例如：

harakiri = 120  # 2 mins

但您确实应该检查哪个端点响应时间太长，web服务发送任何响应需要60秒已经太多了。在

---

还要注意，Nginx^{}对于请求-响应周期的不同部分也有不同的超时参数，但是从错误消息来看，错误似乎与上游（uwsgi）有关。但是为了你自己的理解，你也可以看看那里的相关指令。在