尽管请求尚未完成,但仍重新生成uWSGI worker

我基于此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文件:

[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

我的应用程序在具有24个CPU和128GB RAM的Ubuntu 18.04.3 LTS虚拟机上运行(我知道这可能有些过分,但仅用于测试)。

WAGXZ 回答:尽管请求尚未完成,但仍重新生成uWSGI worker

uwsgi正在重生其工作程序时,似乎harakiri超时已触发。

如果相关响应花费的时间超过 harakiri_seconds ,则

harakiri模式会使uwsgi重新生成工作进程,您可以给它更大的超时时间,例如:

harakiri = 120  # 2 mins

但是您真的应该检查哪个端点花费的时间太长,Web服务发送任何响应的60秒已经太多了。


还要注意,Nginx ngx_http_uwsgi_module对于请求-响应周期的不同部分也具有不同的超时参数,但是从错误消息来看,错误似乎与上游(uwsgi)有关。但是,根据您自己的理解,您也可以查看其中的相关指令。

本文链接:https://www.f2er.com/3151776.html

大家都在问