blocks|key|340354|text|我们使用Django%2Bnginx%2Bgunicorn也遇到了同样的问题。在Gunicorn文档中，我们配置了优雅的超时，几乎没有区别。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|340355|经过一些测试，我们找到了解决方案，要配置的参数是:+timeout+(而不是优雅的超时)。它的工作原理就像一个时钟..|340356|因此，请执行以下操作：|340357|1)打开gunicorn配置文件|340358|2)将超时设置为您需要的值-该值以秒为单位|340359|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|code-block|syntax|javascript|340360|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|V|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

We had the same problem using Django+nginx+gunicorn. From Gunicorn documentation we have configured the graceful-timeout that made almost no difference.

After some testings, we found the solution, the parameter to configure is: timeout (And not graceful timeout). It works like a clock..

So, Do:

1) open the gunicorn configuration file

2) set the TIMEOUT to what ever you need - the value is in seconds

<pre><code>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
</code></pre>

blocks|key|340456|text|在Google+Cloud上，只需在app.yaml中将--timeout+90添加到入口点|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|340457|entrypoint:+gunicorn+-b+:$PORT+main:app+--timeout+90|code-block|syntax|javascript|340458|entityMap^0|I|8|S|C|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|L|$]]

On Google Cloud 
Just add <code>--timeout 90</code> to entrypoint in <code>app.yaml</code>

<pre><code>entrypoint: gunicorn -b :$PORT main:app --timeout 90
</code></pre>

blocks|key|556152|text|使用--log-level+debug运行Gunicorn。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|556153|它应该会给你一个应用程序堆栈跟踪。|556154|entityMap^0|2|H|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

Run Gunicorn with <code>--log-level debug</code>.
It should give you an app stack trace.

blocks|key|340660|text|此终结点是否占用了太多时间？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|340661|也许你使用的是没有异步支持的flask，所以每个请求都会阻塞调用。要创建异步支持而不增加困难，请添加gevent工作线程。|offset|length|style|CODE|340662|有了gevent，一个新的调用将产生一个新的线程，你的应用程序将能够接收更多的请求。|340663|pip+install+gevent
gunicon+....+--worker-class+gevent|code-block|syntax|javascript|340664|entityMap^0|0|1E|6|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@$D|S|E|T|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|V|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Is this endpoint taking too many time?
Maybe you are using flask without asynchronous support, so every request will block the call. To create async support without make difficult, add the <code>gevent</code> worker.
With gevent, a new call will spawn a new thread, and you app will be able to receive more requests
<pre><code>pip install gevent
gunicon .... --worker-class gevent
</code></pre>

blocks|key|556223|text|可能是这个吗？http://docs.gunicorn.org/en/latest/settings.html#timeout|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|556224|其他可能性可能是您的响应时间太长或停滞不前。|556225|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.gunicorn.org/en/latest/settings.html#timeout^0|7|1K|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Could it be this? 
<a href="http://docs.gunicorn.org/en/latest/settings.html#timeout" rel="noreferrer">http://docs.gunicorn.org/en/latest/settings.html#timeout</a>

Other possibilities could be your response is taking too long or is stuck waiting.

blocks|key|556511|text|我在Docker中也遇到了同样的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|556512|在Docker中，我保持训练好的LightGBM模型%2B+Flask服务请求。作为超文本传输协议服务器，我使用gunicorn+19.9.0。当我在我的Mac笔记本电脑上本地运行我的代码时，一切都运行得很完美，但当我在Docker中运行应用程序时，我的POST+JSON请求冻结了一段时间，然后gunicorn+worker就失败了，并出现了[CRITICAL]+WORKER+TIMEOUT异常。|offset|length|style|CODE|556513|我尝试了很多不同的方法，但唯一能解决我的问题的就是添加worker_class=gthread。|556514|下面是我的完整配置：|556515|import+multiprocessing

workers+=+multiprocessing.cpu_count()+*+2+%2B+1
accesslog+=+"-"+#+STDOUT
access_log_format+=+'%25(h)s+%25(l)s+%25(u)s+%25(t)s+"%25(r)s"+%25(s)s+%25(b)s+"%25(q)s"+"%25(D)s"'
bind+=+"0.0.0.0:5000"
keepalive+=+120
timeout+=+120
worker_class+=+"gthread"
threads+=+3|code-block|syntax|javascript|556516|entityMap^0|0|G|8|S|5|1I|F|42|8|4Q|P|0|R|K|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]|$D|W|E|X|F|G]|$D|Y|E|Z|F|G]|$D|10|E|11|F|G]|$D|12|E|13|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|14|8|@$D|15|E|16|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|18|8|@]|9|@]|A|$O|P]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$]]

I've got the same problem in Docker.

In Docker I keep trained <code>LightGBM</code> model + <code>Flask</code> serving requests. As HTTP server I used <code>gunicorn 19.9.0</code>. When I run my code locally on my Mac laptop everything worked just perfect, but when I ran the app in Docker my POST JSON requests were freezing for some time, then <code>gunicorn</code> worker had been failing with <code>[CRITICAL] WORKER TIMEOUT</code> exception. 

I tried tons of different approaches, but the only one solved my issue was adding <code>worker_class=gthread</code>. 

Here is my complete config: 

<pre><code>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
</code></pre>

blocks|key|556916|text|在Azure应用程序服务(Linux应用程序)上运行Flask应用程序的Microsoft+Azure官方文档指出使用超时为600|type|unstyled|depth|inlineStyleRanges|entityRanges|data|556917|gunicorn+--bind=0.0.0.0+--timeout+600+application:app|code-block|syntax|javascript|556918|https://docs.microsoft.com/en-us/azure/app-service/configure-language-python#flask-app|offset|length|556919|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|2E|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|S|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|T|8|@]|9|@$I|U|J|V|1|W]]|A|$]]|$1|K|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|H]]]]

The Microsoft Azure official documentation for running Flask Apps on Azure App Services (Linux App) states the use of timeout as 600
<pre><code>gunicorn --bind=0.0.0.0 --timeout 600 application:app
</code></pre>
<a href="https://docs.microsoft.com/en-us/azure/app-service/configure-language-python#flask-app" rel="noreferrer">https://docs.microsoft.com/en-us/azure/app-service/configure-language-python#flask-app</a>

blocks|key|340425|text|我也遇到过类似的问题，我也试着使用"runserver“来查看是否能找到任何东西，但我得到的只是一条消息Killed|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|340426|所以我认为这可能是资源问题，我继续为实例提供更多的RAM，它起作用了。|340427|entityMap^0|1G|6|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

I had very similar problem, I also tried using "runserver" to see if I could find anything but all I had was a message <code>Killed</code>

So I thought it could be resource problem, and I went ahead to give more RAM to the instance, and it worked.

blocks|key|340687|text|这对我很有效：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|340688|gunicorn+app:app+-b+:8080+--timeout+120+--workers=3+--threads=3+--worker-connections=1000|code-block|syntax|javascript|340689|如果您有eventlet，请添加：|offset|length|style|CODE|340690|--worker-class=eventlet|340691|如果您有gevent，请添加：|340692|--worker-class=gevent|340693|entityMap^0|0|0|4|8|0|0|4|6|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@$I|X|J|Y|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|10|8|@$I|11|J|12|K|L]]|9|@]|A|$]]|$1|Q|3|R|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

This worked for me:

<pre><code>gunicorn app:app -b :8080 --timeout 120 --workers=3 --threads=3 --worker-connections=1000
</code></pre>

If you have <code>eventlet</code> add:

<pre><code>--worker-class=eventlet
</code></pre>

If you have <code>gevent</code> add:

<pre><code>--worker-class=gevent
</code></pre>

blocks|key|556562|text|如果您使用的是GCP，那么您必须为每个实例类型设置worker。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|556563|链接到GCP最佳实践https://cloud.google.com/appengine/docs/standard/python3/runtime|offset|length|556564|entityMap|0|LINK|mutability|MUTABLE|url|https://cloud.google.com/appengine/docs/standard/python3/runtime^0|0|A|1S|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

If you are using GCP then you have to set workers per instance type. 

Link to GCP best practices <a href="https://cloud.google.com/appengine/docs/standard/python3/runtime" rel="nofollow noreferrer">https://cloud.google.com/appengine/docs/standard/python3/runtime</a>

blocks|key|556598|text|对我来说，解决方案是将--timeout+90添加到我的入口点，但它不起作用，因为我定义了两个入口点，一个在app.yaml中，另一个在Dockerfile中。我删除了未使用的入口点，并在另一个入口点中添加了--timeout+90。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|556599|entityMap^0|B|C|2W|C|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

For me, the solution was to add <code>--timeout 90</code> to my entrypoint, but it wasn't working because I had TWO entrypoints defined, one in app.yaml, and another in my Dockerfile. I deleted the unused entrypoint and added <code>--timeout 90</code> in the other.

blocks|key|556780|text|对我来说，这是因为我忘记在数据库服务器上为我的Django设置防火墙规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|556781|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For me, it was because I forgot to setup firewall rule on database server for my Django.

blocks|key|556856|text|弗兰克的回答给我指明了正确的方向。我有一个数字海洋水滴访问一个托管的数字海洋Postgresql数据库。我所需要做的就是将我的快捷方式添加到数据库的“可信来源”中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|556857|(在DO控制台中单击数据库，然后单击设置。编辑可信来源并选择droplet名称(单击可编辑区域，系统将向您建议)。|556858|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Frank's answer pointed me in the right direction. I have a Digital Ocean droplet accessing a managed Digital Ocean Postgresql database. All I needed to do was add my droplet to the database's &quot;Trusted Sources&quot;.
(click on database in DO console, then click on settings. Edit Trusted Sources and select droplet name (click in editable area and it will be suggested to you)).

I have setup gunicorn with 3 workers 30 worker connections and using eventlet worker class. It is setup behind Nginx. After every few requests, I see this in the logs.

<pre><code>[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514
</code></pre>

Why is this happening? How can I figure out whats going wrong?

thanks

Gunicorn worker timeout error

数据库

服务器

防火墙

Django

Linux

JSON

我已经设置了三个工人，30个工人连接和使用eventlet工人类的gunicorn。它是在Nginx后面设置的。在每几个请求之后，我都会在日志中看到这一点。[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)None[INFO] gunicorn.error: Booting worker with pid: 23514为什么会发生这种情况？我怎么才

问Gunicorn工作线程超时错误
EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Gunicorn工作线程超时错误EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Gunicorn工作线程超时错误
EN