uwsgi更便宜的杀死工作人员处理请求 [英] uwsgi cheaper killing workers processing requests
本文介绍了uwsgi更便宜的杀死工作人员处理请求的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
uwsgi正在杀死最老的工作者，即使它正在处理一个请求，导致500.
如何防止uwsgi杀死处理请求的工人，为了便宜？
任何帮助/暗示深深赞赏。
发现另一个类似的帖子，没有回应： UWSGI杀死工人太快 p>
配置：uwsgi版本：2.0.4
＃自动缩放
工作人员= 30
便宜= 2
便宜步骤= 3
便宜 - 算法=积压
便宜 - 超载= 2
记录：
[pid：15601 | 10.83.9.61（）{28个变量，368字节} [Fri Sep 30 02:00:34 2016] POST / xxxxxxxxxxxx =>在151个毫秒（HTTP / 1.1 200）中产生了257个字节，72个字节中的2个头（核心0上的1个开关）
[pid：15601 | app：0 | req：14/79] 10.83.9.61（）{28 vars in 368 bytes} [Fri Sep 30 02:00:35 2016] POST / xxxxxxxxxxxx =>在649毫秒（HTTP / 1.1 200）中生成了186个字节，72个字节中的2个头（核心0上的1个开关）。变量为369字节} [Fri Sep 30 03:30:08 2016] POST / xxxxxxxxxxxx => （新的PID：21009）
重新生成的uWSGI工作者4（新的PID： 21010）
重生的uWSGI工作人员5（新的pid：21011）
[pid：15601 | app：0 | req：15/81] 10.83.9.62（）{28 vars in 370 bytes} [Fri Sep 30 03:30:09 2016] POST / xxxxxxxxxxxx =>在3046毫秒（HTTP / 1.1 200）中生成了186个字节，72个字节中的2个头（核心0上的2个开关）
[pid：15600 | app：0 | req：22/82] 10.83.9.63（）{28变量为370字节} [Fri Sep 30 03:30:10 2016] POST / xxxxxxxxxxxx =>在3347 msecs（HTTP / 1.1 500）中生成0个字节127个字节中的2个头（核心0上的7个开关）
worker 2成功终止（pid：15600）< ----------- - 15600被中断，返回500（线以上）
uWSGI工人2 cheaped。
[pid：15601 | app：0 | req：16/83] 10.83.9.62（）{28 vars in 369 bytes} [Fri Sep 30 03:30:12 2016] POST / xxxxxxxxxxxx =>在2560毫秒（HTTP / 1.1 500）中生成0字节127字节的2个头（核心0上的3个开关）
[pid：21010 | app：0 | req：19/84] 10.83.9.63（）{28变量为369字节} [Fri Sep 30 03:30:12 2016] POST / xxxxxxxxxxxx =>在2931 msecs（HTTP / 1.1 200）中生成了186个字节，72个字节中的2个头（核心0上的4个开关）
worker 3 kill successfully（pid：15601）< ----------- - 15601 pid被打断，500（行）以上
uWSGI工人3倒下。
[pid：21011 | app：0 | req：22/85] 10.83.9.61（）{28 vars in 370 bytes} [Fri Sep 30 03:30:12 2016] POST / xxxxxxxxxxxx =>在3236毫秒（HTTP / 1.1 200）中生成了186个字节，72个字节（核心0上的4个开关）中的2个标题
[pid：21009 | app：0 | req：7/86] 10.83.9.61（）{28变量为370字节} [Fri Sep 30 03:30:12 2016] POST / xxxxxxxxxxxx =>在3532 msecs（HTTP / 1.1 500）中生成0个字节127个字节中的2个头（核心0上的4个开关）
worker 1成功终止（pid：21009）< ----------- - 15601 pid被打断，返回500（线以上）
uWSGI worker 1 cheaped。
[pid：21011 | app：0 | req：23/87] 10.83.9.63（）{28变量为369字节} [Fri Sep 30 03:30:15 2016] POST / xxxxxxxxxxxx => （新的PID：21013）
重新生成的uWSGI worker 2（new pid：21013）
重新生成的uWSGI worker 1（新的pid：21013）
重新生成的uWSGI worker 2 21014）
重生的uWSGI工作人员3（新的pid：21015）
[pid：21011 | app：0 | req：24/88] 10.83.9.61（）{28 vars in 369 bytes} [Fri Sep 30 03:30:17 2016] POST / xxxxxxxxxxxx =>在2546毫秒（HTTP / 1.1 200）中产生了186个字节，72个字节中的2个头（核心0上的3个开关）
[pid：21010 | app：0 | req：20/89] 10.83.9.62（）{28变量为370字节} [Fri Sep 30 03:30:15 2016] POST / xxxxxxxxxxxx =>在4845 msecs（HTTP / 1.1 500）中生成0个字节127个字节中的2个头（核心0上的6个开关）
worker 4个成功死亡（pid：21010）< ----------- - 15601 pid中断，500（行）以上
uWSGI工人4 chepped。
[pid：21015 | app：0 | req：17/90] 10.83.9.61（）{28变量为369字节} [Fri Sep 30 03:30:18 2016] POST / xxxxxxxxxxxx =>在2402 msecs（HTTP / 1.1 200）中生成了186个字节，72个字节中的2个头（核心0上的3个开关）
worker 5 kill successfully（pid：21011）< ----------- - pid 15601被中断，返回500（上面的行）
解决方案<错误修复&合并于2016年8月。
https：/ /github.com/unbit/uwsgi/issues/1288
I have a very basic flask application under uwsgi, managed by signals under supervisorctl. I use cheaper for scaling workers and ran into very disturbing situation. uwsgi is killing oldest worker, even when it is processing a request, causing 500.
How to prevent uwsgi from killing workers processing the request, for the sake of cheaping?
Any help/hints deeply appreciated. Found another similar post without response: UWSGI killing workers too fast
Config: uwsgi version: 2.0.4
# Auto-scaling workers = 30 cheaper = 2 cheaper-step = 3 cheaper-algo = backlog cheaper-overload = 2Logs:
[pid: 15601|app: 0|req: 13/78] 10.83.9.61 () {28 vars in 368 bytes} [Fri Sep 30 02:00:34 2016] POST /xxxxxxxxxxxx => generated 257 bytes in 151 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0) [pid: 15601|app: 0|req: 14/79] 10.83.9.61 () {28 vars in 368 bytes} [Fri Sep 30 02:00:35 2016] POST /xxxxxxxxxxxx => generated 186 bytes in 649 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0) [pid: 15600|app: 0|req: 21/80] 10.83.9.62 () {28 vars in 369 bytes} [Fri Sep 30 03:30:08 2016] POST /xxxxxxxxxxxx => generated 186 bytes in 2696 msecs (HTTP/1.1 200) 2 headers in 72 bytes (3 switches on core 0) Respawned uWSGI worker 1 (new pid: 21009) Respawned uWSGI worker 4 (new pid: 21010) Respawned uWSGI worker 5 (new pid: 21011) [pid: 15601|app: 0|req: 15/81] 10.83.9.62 () {28 vars in 370 bytes} [Fri Sep 30 03:30:09 2016] POST /xxxxxxxxxxxx => generated 186 bytes in 3046 msecs (HTTP/1.1 200) 2 headers in 72 bytes (2 switches on core 0) [pid: 15600|app: 0|req: 22/82] 10.83.9.63 () {28 vars in 370 bytes} [Fri Sep 30 03:30:10 2016] POST /xxxxxxxxxxxx => generated 0 bytes in 3347 msecs (HTTP/1.1 500) 2 headers in 127 bytes (7 switches on core 0) worker 2 killed successfully (pid: 15600) <------------- pid 15600 was interrupted, returned 500 (line above) uWSGI worker 2 cheaped. [pid: 15601|app: 0|req: 16/83] 10.83.9.62 () {28 vars in 369 bytes} [Fri Sep 30 03:30:12 2016] POST /xxxxxxxxxxxx => generated 0 bytes in 2560 msecs (HTTP/1.1 500) 2 headers in 127 bytes (3 switches on core 0) [pid: 21010|app: 0|req: 19/84] 10.83.9.63 () {28 vars in 369 bytes} [Fri Sep 30 03:30:12 2016] POST /xxxxxxxxxxxx => generated 186 bytes in 2931 msecs (HTTP/1.1 200) 2 headers in 72 bytes (4 switches on core 0) worker 3 killed successfully (pid: 15601) <------------- pid 15601 was interrupted, returned 500 (line above) uWSGI worker 3 cheaped. [pid: 21011|app: 0|req: 22/85] 10.83.9.61 () {28 vars in 370 bytes} [Fri Sep 30 03:30:12 2016] POST /xxxxxxxxxxxx => generated 186 bytes in 3236 msecs (HTTP/1.1 200) 2 headers in 72 bytes (4 switches on core 0) [pid: 21009|app: 0|req: 7/86] 10.83.9.61 () {28 vars in 370 bytes} [Fri Sep 30 03:30:12 2016] POST /xxxxxxxxxxxx => generated 0 bytes in 3532 msecs (HTTP/1.1 500) 2 headers in 127 bytes (4 switches on core 0) worker 1 killed successfully (pid: 21009) <------------- pid 15601 was interrupted, returned 500 (line above) uWSGI worker 1 cheaped. [pid: 21011|app: 0|req: 23/87] 10.83.9.63 () {28 vars in 369 bytes} [Fri Sep 30 03:30:15 2016] POST /xxxxxxxxxxxx => generated 186 bytes in 1614 msecs (HTTP/1.1 200) 2 headers in 72 bytes (1 switches on core 0) Respawned uWSGI worker 1 (new pid: 21013) Respawned uWSGI worker 2 (new pid: 21014) Respawned uWSGI worker 3 (new pid: 21015) [pid: 21011|app: 0|req: 24/88] 10.83.9.61 () {28 vars in 369 bytes} [Fri Sep 30 03:30:17 2016] POST /xxxxxxxxxxxx => generated 186 bytes in 2546 msecs (HTTP/1.1 200) 2 headers in 72 bytes (3 switches on core 0) [pid: 21010|app: 0|req: 20/89] 10.83.9.62 () {28 vars in 370 bytes} [Fri Sep 30 03:30:15 2016] POST /xxxxxxxxxxxx => generated 0 bytes in 4845 msecs (HTTP/1.1 500) 2 headers in 127 bytes (6 switches on core 0) worker 4 killed successfully (pid: 21010) <------------- pid 15601 was interrupted, returned 500 (line above) uWSGI worker 4 cheaped. [pid: 21015|app: 0|req: 17/90] 10.83.9.61 () {28 vars in 369 bytes} [Fri Sep 30 03:30:18 2016] POST /xxxxxxxxxxxx => generated 186 bytes in 2402 msecs (HTTP/1.1 200) 2 headers in 72 bytes (3 switches on core 0) worker 5 killed successfully (pid: 21011) <------------- pid 15601 was interrupted, returned 500 (line above)
解决方案Bug fixed & merged in August 2016.
https://github.com/unbit/uwsgi/issues/1288
https://github.com/unbit/uwsgi/commit/f5dd0b855d0d21be62534dc98375fae2cd7c13f0
这篇关于uwsgi更便宜的杀死工作人员处理请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
查看全文
