【问题标题】:uWSGI worker respawning although the request is not yet finished尽管请求尚未完成,但 uWSGI 工作人员正在重生
【发布时间】:2019-11-06 13:33:50
【问题描述】:

我基于这个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 秒后重新生成其 worker 时,nginx 日志中的错误也出现了。这不会一直发生,但在大多数情况下(~90%)都是这样。有时它只是有效,所以我认为,这一定是时间问题或类似的问题。

如果我的猜测是正确的,工人寿命的增加应该会减少 nginx 日志中错误事件的数量。实际上,uWSGI 不应该只是在请求未完成时重新生成 worker,那么问题是什么?

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

我的应用在 Ubuntu 18.04.3 LTS 虚拟机上运行,​​该虚拟机具有 24 个 CPU 和 128GB RAM(我知道这可能有点矫枉过正,但它只是为了测试。)

【问题讨论】:

    标签: python nginx flask uwsgi


    【解决方案1】:

    由于uwsgi 正在重生其工作人员,似乎正在触发harakiri 超时。

    harakiri 模式使uwsgi 重新启动工作进程,如果相关响应时间超过 harakiri_seconds,您可以给它一个更大的超时时间,例如:

    harakiri = 120  # 2 mins
    

    但是您确实应该检查哪个端点需要这么长时间才能响应,Web 服务发送任何响应的 60 秒已经太多了。


    另外请注意,Nginx ngx_http_uwsgi_module 对于请求-响应周期的不同部分也有不同的超时参数,但从错误消息来看,错误似乎与上游有关(uwsgi)。但为了自己的理解,你也可以看看那里的相关指令。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2023-03-23
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-08-11
      • 2023-03-25
      相关资源
      最近更新 更多