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

我基于此编写了一个烧瓶应用程序

我的应用程序的行为就像一种文件分发器。它接受文件并将其分发到其他系统上的不同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文件：

[uwsgi]
module = wsgi:app

master = true
processes = 48
threads = 2
enable-threads = True

limit-as = 512

disable-logging = True
buffer-size = 65535
max-worker-lifetime = 60

socket = myproject.sock
chmod-socket = 660
vacuum = true

die-on-term = true

#location of log files
logto = /var/log/uwsgi/%n.log

---

我的应用程序运行在一台Ubuntu18.04.3 LTS虚拟机上，有24个CPU和128GB内存（我知道这可能是一种过度使用，但它只是为了测试。）

随着

uwsgi

的工作人员重生，似乎触发了

harakiri

超时

harakiri

模式使

uwsgi

重新启动工作进程如果相关响应花费的时间超过harakiri_秒，您可以给它一个更大的超时时间，例如：

harakiri = 120  # 2 mins

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

---

还要注意，Nginx对于请求-响应周期的不同部分也有不同的超时参数，但是从错误消息来看，错误似乎与上游相关（

uwsgi

）。但是为了您自己的理解，您也可以看看相关的指令