我正在运行带有gunicorn的烧瓶应用程序(rest api),我几乎每隔30秒就会看到一批[CRITICAL] WORKER TIMEOUT (pid:14727)
。
我的设置如下:
gunicorn --worker-class gevent \
--timeout 30 --graceful-timeout 20
--max-requests-jitter 2000 --max-requests 1500
-w 50
--log-level DEBUG --capture-output
--bind 0.0.0.0:5000 run:app
我看到上一篇帖子曾说过要在这个方面投入更多内存,但从外观来看:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 513926
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 131071
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 1550298
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
堆是无限的,堆栈大小略超过8Mb。
+0000] [26657] [DEBUG] GET /timer
[2017-01-21 14:07:30 +0000] [26657] [DEBUG] GET /timer
[2017-01-21 14:07:33 +0000] [26657] [DEBUG] GET /timer
[2017-01-21 14:07:33 +0000] [26652] [DEBUG] GET /timer
10.193.80.149 - - [21/Jan/2017:14:07:34 +0000] "GET /timer?id=699ec59eccd3fb929b3dd7707e542ed15acd4181:6f136b54-2cb5-42ef-9def-f69caaba57ef HTTP/1.1" 200 - "-" "-"
10.193.80.147 - - [21/Jan/2017:14:07:35 +0000] "GET /timer?id=e7963c53603ed9249b0aa557d8a64cea89fb0bf4:6f136b54-2cb5-42ef-9def-f69caaba57ef HTTP/1.1" 200 - "-" "-"
10.193.80.150 - - [21/Jan/2017:14:07:35 +0000] "GET /timer?id=4b750805193fb4d00c3ce1465c266ed932a24e55:6f136b54-2cb5-42ef-9def-f69caaba57ef HTTP/1.1" 200 - "-" "-"
[2017-01-21 14:07:37 +0000] [26657] [DEBUG] GET /timer
[2017-01-21 14:07:37 +0000] [26657] [DEBUG] GET /timer
[2017-01-21 14:07:37 +0000] [26635] [CRITICAL] WORKER TIMEOUT (pid:27202)
[2017-01-21 14:07:37 +0000] [26635] [CRITICAL] WORKER TIMEOUT (pid:27205)
我注意到只有少数工人总是在做工作26657
,26652
26651
其他一切似乎都在给我Worker timeout
答案 0 :(得分:0)
你有一些请求需要超过30秒才能完成,这就是他们被杀的原因。之一:
top
检查CPU或RAM是否饱和。--timeout 30
更改为更高的数字来增加超时。这真是最糟糕的想法,因为你没有解决你的烧瓶应用程序对传入请求响应缓慢的根本问题。另外,杀死长时间运行的请求通常有助于其他烧瓶线程也不会遇到资源问题。