我已经设置了gunicorn与3个工人，30个工人连接和使用eventlet工人类。它被设置在Nginx后面。每请求几次，我就会在日志里看到这个。
[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514
为什么会这样?我怎样才能知道哪里出了问题呢?
当前回答
检查你的工人没有被健康检查杀死。长请求可能会阻塞健康检查请求，worker会被平台杀死，因为平台认为worker没有响应。
例如，如果您有一个25秒长的请求，并且活动检查被配置为每10秒命中同一服务中的不同端点，1秒超时，并重试3次，这就给出了10+1*3 ~ 13秒，您可以看到它会触发一些时间，但并不总是如此。
如果是这种情况，解决方案是重新配置您的活动检查(或您的平台使用的任何健康检查机制)，以便它可以等待您的典型请求完成。或者允许更多的线程——这样可以确保健康检查不会阻塞足够长的时间来触发worker kill。
你可以看到，增加更多的工人可能有助于(或隐藏)这个问题。
其他回答
弗兰克的回答给我指明了正确的方向。我有一个数字海洋液滴访问管理数字海洋Postgresql数据库。我所需要做的就是将我的液滴添加到数据库的“可信来源”。
(在DO控制台点击数据库，然后点击设置。编辑Trusted Sources，选择液滴名称(在可编辑区域点击，会提示)。
对我来说，这是因为我忘记在数据库服务器上为我的Django设置防火墙规则。
这招对我很管用:
gunicorn app:app -b :8080 --timeout 120 --workers=3 --threads=3 --worker-connections=1000
如果你有eventlet，添加:
--worker-class=eventlet
如果你有gevent添加:
--worker-class=gevent
我们在使用Django+nginx+gunicorn时也遇到了同样的问题。从Gunicorn文档中，我们配置了优雅的超时，几乎没有什么不同。
经过一些测试，我们找到了解决方案，要配置的参数是: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
如果你已经更改了django项目的名称，你也应该去
cd /etc/systemd/system/
then
sudo nano gunicorn.service
然后验证在绑定行的末尾，应用程序名称已更改为新的应用程序名称
