我已经设置了gunicorn与3个工人，30个工人连接和使用eventlet工人类。它被设置在Nginx后面。每请求几次，我就会在日志里看到这个。
[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514
为什么会这样?我怎样才能知道哪里出了问题呢?
当前回答
对我来说，解决方案是在我的入口点上添加——timeout 90，但它不起作用，因为我定义了两个入口点，一个在app.yaml中，另一个在Dockerfile中。我删除了未使用的入口点，并在另一个入口点添加了——timeout 90。
其他回答
弗兰克的回答给我指明了正确的方向。我有一个数字海洋液滴访问管理数字海洋Postgresql数据库。我所需要做的就是将我的液滴添加到数据库的“可信来源”。
(在DO控制台点击数据库，然后点击设置。编辑Trusted Sources，选择液滴名称(在可编辑区域点击，会提示)。
检查你的工人没有被健康检查杀死。长请求可能会阻塞健康检查请求，worker会被平台杀死，因为平台认为worker没有响应。
例如，如果您有一个25秒长的请求，并且活动检查被配置为每10秒命中同一服务中的不同端点，1秒超时，并重试3次，这就给出了10+1*3 ~ 13秒，您可以看到它会触发一些时间，但并不总是如此。
如果是这种情况，解决方案是重新配置您的活动检查(或您的平台使用的任何健康检查机制)，以便它可以等待您的典型请求完成。或者允许更多的线程——这样可以确保健康检查不会阻塞足够长的时间来触发worker kill。
你可以看到，增加更多的工人可能有助于(或隐藏)这个问题。
如果你已经更改了django项目的名称，你也应该去
cd /etc/systemd/system/
then
sudo nano gunicorn.service
然后验证在绑定行的末尾，应用程序名称已更改为新的应用程序名称
我在Docker中也遇到了同样的问题。
在Docker中，我保持训练过的LightGBM模型+ Flask服务请求。作为HTTP服务器，我使用gunicorn 19.9.0。当我在我的Mac笔记本电脑上本地运行我的代码时，一切都很完美，但当我在Docker中运行应用程序时，我的POST JSON请求冻结了一段时间，然后gunicorn工人已经失败了[CRITICAL]工人超时异常。
我尝试了大量不同的方法，但唯一解决我的问题的是添加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
会是这样吗? http://docs.gunicorn.org/en/latest/settings.html#timeout
其他的可能是你的回复时间太长或者被困在等待中。
