我已经设置了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。

你可以看到,增加更多的工人可能有助于(或隐藏)这个问题。

其他回答

如果你已经更改了django项目的名称,你也应该去

cd /etc/systemd/system/

then

sudo nano gunicorn.service

然后验证在绑定行的末尾,应用程序名称已更改为新的应用程序名称

检查你的工人没有被健康检查杀死。长请求可能会阻塞健康检查请求,worker会被平台杀死,因为平台认为worker没有响应。

例如,如果您有一个25秒长的请求,并且活动检查被配置为每10秒命中同一服务中的不同端点,1秒超时,并重试3次,这就给出了10+1*3 ~ 13秒,您可以看到它会触发一些时间,但并不总是如此。

如果是这种情况,解决方案是重新配置您的活动检查(或您的平台使用的任何健康检查机制),以便它可以等待您的典型请求完成。或者允许更多的线程——这样可以确保健康检查不会阻塞足够长的时间来触发worker kill。

你可以看到,增加更多的工人可能有助于(或隐藏)这个问题。

我们在使用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

对我来说,最简单的方法是在你的app.py存在的文件夹中创建一个新的config.py文件,并在其中放入超时和所有你想要的特殊配置:

timeout = 999

然后在指向这个配置文件的同时运行服务器

gunicorn -c config.py --bind 0.0.0.0:5000 wsgi:app

注意,要使这条语句工作,还需要将wsgi.py放在具有以下内容的同一目录中

from myproject import app

if __name__ == "__main__":
    app.run()

干杯!

使用——log-level debug运行Gunicorn。

它应该会给你一个应用程序堆栈跟踪。