Question

我已经设置了3个工人30个工人连接和使用eventlet工人类的gunicorn。它是在Nginx背后设置的。在每几个请求之后，我在日志中看到了这一点。

[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514

为什么会这样？我怎么能弄清楚什么是错的？

感谢

Answer 1

使用Django + nginx + gunicorn我们遇到了同样的问题。从Gunicorn文档中我们已经配置了优雅超时，这几乎没有任何区别。

经过一些测试，我们找到了解决方案，配置的参数是：timeout（而不是graceful timeout）。它就像一个时钟......

所以，做：

1）打开gunicorn配置文件

2）将TIMEOUT设置为您需要的值 - 以秒为单位

NUM_WORKERS=3
TIMEOUT=120

exec gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--timeout $TIMEOUT \
--log-level=debug \
--bind=127.0.0.1:9000 \
--pid=$PIDFILE

Answer 2

使用--log-level=DEBUG运行Gunicorn。

它应该为您提供应用程序堆栈跟踪。

Answer 3

在Google Cloud上只需将--timeout 90添加到app.yaml

中的入口点即可

entrypoint: gunicorn -b :$PORT main:app --timeout 90

Answer 4

可能是这个吗？ http://docs.gunicorn.org/en/latest/settings.html#timeout

其他可能性可能是你的反应时间过长或等待时间过长。

Answer 5

此端点是否花费太多时间？

也许您正在使用不带有异步支持的flask，所以每个请求都将阻止该调用。要轻松创建异步支持，请添加gevent工作器。

使用gevent，新的调用将产生一个新线程，您的应用将能够接收更多请求

pip install gevent
gunicon .... --worker-class gevent

Answer 6

您需要使用其他工作类型类，如 gevent 或 tornado 等异步，请参阅此更多说明：第一个解释：

如果您希望应用程序代码在请求处理期间需要长时间暂停，则可能还需要安装Eventlet或Gevent

第二个：

默认同步工作者假定您的应用程序在CPU和网络带宽方面受资源限制。通常这意味着您的应用程序不应该执行任何需要不确定时间的事情。例如，对互联网的请求符合此标准。在某些时候，外部网络将以客户端堆积在服务器上的方式失败。

Answer 7

我遇到了类似的问题，我也尝试使用“runserver”来查看是否能找到任何内容，但我所拥有的只是一条消息Killed

所以我认为这可能是资源问题，我继续为实例提供更多内存，并且它有效。

Answer 8

用于在 Azure 应用服务（Linux 应用）上运行 Flask 应用的 Microsoft Azure 官方文档声明使用超时为 600

gunicorn --bind=0.0.0.0 --timeout 600 application:app

https://docs.microsoft.com/en-us/azure/app-service/configure-language-python#flask-app

Answer 9

WORKER TIMEOUT表示您的应用程序无法在定义的时间内响应请求。您可以使用gunicorn timeout settings进行设置。某些应用程序需要比其他应用程序更多的时间来响应。

可能会影响此的另一件事是choosing the worker type

默认同步工作器假定您的应用程序在CPU和网络带宽方面受资源限制。通常，这意味着您的应用程序不应执行任何花费时间不确定的事情。花费时间不确定的一个例子是对互联网的请求。在某些时候，外部网络将以客户端将堆积在您的服务器上的方式失效。因此，从这个意义上讲，任何向API发出传出请求的Web应用程序都将从异步工作程序中受益。

当遇到与您相同的问题时（我试图使用Docker Swarm部署应用程序），我试图增加超时时间并使用另一种类型的worker类。但是都失败了。

然后我突然意识到我将我的资源限制为太低，用于我的撰写文件中的服务。就我而言，这就是使应用程序变慢的原因

deploy:
  replicas: 5
  resources:
    limits:
      cpus: "0.1"
      memory: 50M
  restart_policy:
    condition: on-failure

因此，我建议您首先检查哪些因素会使您的应用程序变慢

Answer 10

这对我有用：

gunicorn app:app -b :8080 --timeout 120 --workers=3 --threads=3 --worker-connections=1000

如果您有eventlet，请添加：

--worker-class=eventlet

如果您有gevent，请添加：

--worker-class=gevent

Answer 11

如果使用的是GCP，则必须为每种实例类型设置工作程序。

链接到GCP最佳做法https://cloud.google.com/appengine/docs/standard/python3/runtime

Answer 12

超时是解决此问题的关键参数。

但是这不适合我。

当我设置worker = 1时，我发现没有gunicorn超时错误。

当我查看我的代码时，我在服务器初始化中发现了一些 socket连接（socket.send和socket.recv）。

socket.recv将阻止我的代码，这就是为什么当worker> 1

时总是超时的原因

希望向对我有问题的人提供一些想法

Answer 13

我在Docker中也遇到了同样的问题。

在Docker中，我保持训练有素的LightGBM模型+ Flask服务请求。作为HTTP服务器，我使用了gunicorn 19.9.0。当我在Mac笔记本电脑上本地运行代码时，一切正常，但是当我在Docker中运行该应用程序时，我的POST JSON请求冻结了一段时间，然后gunicorn工作人员失败，出现了[CRITICAL] WORKER TIMEOUT异常。

我尝试了无数种不同的方法，但是解决我问题的唯一方法是添加worker_class=gthread。

这是我完整的配置：

import multiprocessing

workers = multiprocessing.cpu_count() * 2 + 1
accesslog = "-" # STDOUT
access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(q)s" "%(D)s"'
bind = "0.0.0.0:5000"
keepalive = 120
timeout = 120
worker_class = "gthread"
threads = 3

Answer 14

对我来说，解决方案是将--timeout 90添加到我的入口点，但是没有用，因为我定义了两个入口点，一个在app.yaml中，另一个在我的Dockerfile中。我删除了未使用的入口点，并在另一个入口点添加了--timeout 90。

Answer 15

对我来说，这是因为我忘记为Django在数据库服务器上设置防火墙规则。

Answer 16

弗兰克的回答为我指明了正确的方向。我有一个Digital Ocean小滴正在访问一个托管的Digital Ocean Postgresql数据库。我要做的就是将我的小滴添加到数据库的“受信任的源”中。

（在DO控制台中单击数据库，然后单击设置。编辑Trusted Sources并选择Droplet名称（在可编辑区域中单击，将向您建议）。

Gunicorn工人超时错误

16 个答案: