UWSGI杀死工人太快了 [英] UWSGI killing workers too fast

查看：1359
本文介绍了UWSGI杀死工人太快了的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

在我的webapp中遇到了一个bug，这个bug已经有一年多的时间了，当我在新实例上切换到UWSGI来加快速度时，我遇到了这个问题。 b

我的应用程序有快速添加模式窗口，允许用户添加一个新的客户到数据库，并立即去该用户的购物车。因此，该模块向 / customers / quick_create / 发出 POST 请求，重定向到 / cart / 10000 ，其中 10000 是客户的ID。然后有趣的开始。



因为检查 / cart 来看看是否有客户该ID与否，我注意到，检查被激活，当这个请求被做，用户被重定向到后备链接，到实际的购物车。这是执行检查的代码： 

  q = Customer.query.filter_by（id = cust）.first（）
如果q是None：
 return redirect（'/ customers /'）

支票在那里，因为有人可能不仅通过这种模式到达那个阶段。而且，有时用户会到达后备网址，有时会到达 / cart 。在所有情况中，客户实际上是创建的，我可以稍后访问并在数据库中查看它，所以出于某种原因，此SQL查询找不到具有该ID的客户。 p>

我检查了USGI日志，这是一个简短的摘录： 

  /usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py:324：警告：第1行的列'refill_date'的数据被截断
 cursor.execute（statement，parameters）
 [pid：5197 | app：0 | req：1/1] 123.123.123.123（）{54 vars in 1285 bytes} [Tue Feb 3 14:34:59 2015] POST / customers / quick_create / =>在43毫秒（HTTP / 1.1 302）中生成237个字节421个字节中的4个头（核心0上的2个开关）
 Tue Feb 3 14:34:59 2015  -  ...进程5197的工作完成。再见！ 
 [pid：5200 | app：0 | req：1/2] 123.123.123.123（）{48 vars in 1118 bytes} [Tue Feb 3 14:35:00 2015] GET / cart / 16198 / => ;在42毫秒（HTTP / 1.1 302）中生成229个字节417字节（核心0上的1个开关）中的4个标题
 Tue Feb 3 14:35:00 2015  -  ...进程5200的工作完成。再见！ 
 Tue Feb 3 14:35:00 2015  - 工人1成功杀死（pid：5197）
星期二2月3日14:35:00  - 重生的uWSGI工人1（新的pid：5218）
星期二2月3日14:35:00  - 工人4杀死成功（pid：5200）
星期二2月3 14:35:00  - 重生的uWSGI工人4（新的pid：5219）
星期二2月3 14:35:00 2015  - 映射工作人员4到CPU：0 
 Tue Feb 3 14:35:00 2015  - 映射工作人员1到CPU：0 
 Tue Feb 3 14:35:03 2015  - 在解释器0x1dd1630 pid：5219（默认应用程序）
 2月3日14:35:03准备好WSGI应用程序0（安装点=''）在uwsgi上挂载/ 
星期二2月3日14： 2015年3月15日 -  WSGI应用程序0（安装点=''）准备在解释器0x1dd1630 pid：5218（默认应用程序）
 2月3日14:35:03 2015年 - 安装uwsgi上/ 
 GET / customers / => [pid：5199 | app：0 | req：1/3] 123.123.123.123（）{48 vars in 1110 bytes} [Tue Feb 3 14:35:00 2015]在3402 msecs（HTTP / 1.1 200）中生成3704543个字节370个字节中的3个头（核心0上的18个开关）
 Tue Feb 3 14:35:03 2015  -  ...进程5199的工作完成。再见！ 
 Tue Feb 3 14:35:04 2015  - 工人3成功杀死（pid：5199）
 Tue Feb 3 14:35:04 2015  - 重生的uWSGI工人3（新的pid：5226）
星期二2月3日14:35:04映射工作人员3到CPU：0 
星期二2月3日14:35:05 WSGI应用程序0（安装点=''）在解释器1秒准备就绪0x1dd1630 pid： 5226（默认应用程序）
 2月3日14:35:05  - 在/ 
上挂载uwsgi

这是我的UWSGI配置：

 < uwsgi> 
< plugin> python< / plugin> 
< socket> /run/uwsgi/app/example.com/example.com.socket< / socket> 
< pythonpath> /srv/www/example.com/application/< / pythonpath> 
< app mountpoint =/> 
< script> uwsgi< / script> 
< / app> 
 
< master /> 
< callable> app< / callable> 
< module> app< / module> 
<进程> 4< /进程> 
< harakiri> 60< / harakiri> 
< reload-mercy> 8< / reload-mercy> 
< cpu-affinity> 1< / cpu-affinity> 
< stats> /tmp/stats.socket< / stats> 
< max-requests> 2000< / max-requests> 
< limit-as> 512< / limit-as> 
< reload-on-as> 256< / reload-on-as> 
< reload-on-rss> 192< / reload-on-rss> 
< no-orphans /> 
< vacuum /> 
< lazy-apps /> 
< / uwsgi>

我真的觉得很奇怪，UWSGI会在请求之后杀死那个工作者。当有一些静态文件的请求时，每个请求都有新的PID。



在mod_wsgi和Apache实例上不会发生这种情况。 CPU不时高达100％，但写入时的平均负载为OK， 0.25,0.22,0.15 ，RAM使用率约为300的900 MB。

任何人都可以指向一个正确的方向吗？谢谢

解决方案

跑到这个问题：

问题解决&处理请求/ 39808544＃39808544> uwsgi更便宜的处理请求处理工人

合并于2016年8月。



https： //github.com/unbit/uwsgi/issues/1288



https://github.com/unbit/uwsgi/commit/f5dd0b855d0d21be62534dc98375fae2cd7c13f0


I have encountered one bug in my webapp that has been working for more than a year before, and when I switched to UWSGI on a new instance to speed things up a bit, I encountered this.

My app has "quick add" modal window which allows user to add a new customer to the database, and immediately go to the shopping cart for that user. So, the module makes a POST request to /customers/quick_create/, which does the redirection to /cart/10000, where 10000 is the ID of the customer. Then the fun starts.

As there is a check on that /cart to see whether there is a customer with that ID or not, I noticed that check gets activated and when that request is made, the user is redirected to the fallback link, to to the actual cart. This is the code that performs the check:

q = Customer.query.filter_by(id=cust).first()
            if q is None:
                return redirect('/customers/')

The check is there because someone might get to that stage not only via that modal. And, sometimes the user gets to the fallback url, sometimes to the /cart. In all cases, the customer is actually created, I can go later to it and see it in the database, so for some reason, this SQL query doesn't find a customer with that ID.

I have checked the USGI logs and this is a short excerpt:

/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py:324: Warning: Data truncated for column 'refill_date' at row 1
  cursor.execute(statement, parameters)
[pid: 5197|app: 0|req: 1/1] 123.123.123.123 () {54 vars in 1285 bytes} [Tue Feb  3 14:34:59 2015] POST /customers/quick_create/ => generated 237 bytes in 43 msecs (HTTP/1.1 302) 4 headers in 421 bytes (2 switches on core 0)
Tue Feb  3 14:34:59 2015 - ...The work of process 5197 is done. Seeya!
[pid: 5200|app: 0|req: 1/2] 123.123.123.123 () {48 vars in 1118 bytes} [Tue Feb  3 14:35:00 2015] GET /cart/16198/ => generated 229 bytes in 42 msecs (HTTP/1.1 302) 4 headers in 417 bytes (1 switches on core 0)
Tue Feb  3 14:35:00 2015 - ...The work of process 5200 is done. Seeya!
Tue Feb  3 14:35:00 2015 - worker 1 killed successfully (pid: 5197)
Tue Feb  3 14:35:00 2015 - Respawned uWSGI worker 1 (new pid: 5218)
Tue Feb  3 14:35:00 2015 - worker 4 killed successfully (pid: 5200)
Tue Feb  3 14:35:00 2015 - Respawned uWSGI worker 4 (new pid: 5219)
Tue Feb  3 14:35:00 2015 - mapping worker 4 to CPUs: 0
Tue Feb  3 14:35:00 2015 - mapping worker 1 to CPUs: 0
Tue Feb  3 14:35:03 2015 - WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1dd1630 pid: 5219 (default app)
Tue Feb  3 14:35:03 2015 - mounting uwsgi on /
Tue Feb  3 14:35:03 2015 - WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1dd1630 pid: 5218 (default app)
Tue Feb  3 14:35:03 2015 - mounting uwsgi on /
[pid: 5199|app: 0|req: 1/3] 123.123.123.123 () {48 vars in 1110 bytes} [Tue Feb  3 14:35:00 2015] GET /customers/ => generated 3704543 bytes in 3402 msecs (HTTP/1.1 200) 3 headers in 370 bytes (18 switches on core 0)
Tue Feb  3 14:35:03 2015 - ...The work of process 5199 is done. Seeya!
Tue Feb  3 14:35:04 2015 - worker 3 killed successfully (pid: 5199)
Tue Feb  3 14:35:04 2015 - Respawned uWSGI worker 3 (new pid: 5226)
Tue Feb  3 14:35:04 2015 - mapping worker 3 to CPUs: 0
Tue Feb  3 14:35:05 2015 - WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x1dd1630 pid: 5226 (default app)
Tue Feb  3 14:35:05 2015 - mounting uwsgi on /

This is my UWSGI config:

 <uwsgi>
     <plugin>python</plugin>
     <socket>/run/uwsgi/app/example.com/example.com.socket</socket>
     <pythonpath>/srv/www/example.com/application/</pythonpath>
     <app mountpoint="/">
         <script>uwsgi</script>
     </app>

     <master/>
     <callable>app</callable>
     <module>app</module>
     <processes>4</processes>
     <harakiri>60</harakiri>
     <reload-mercy>8</reload-mercy>
     <cpu-affinity>1</cpu-affinity>
     <stats>/tmp/stats.socket</stats>
     <max-requests>2000</max-requests>
     <limit-as>512</limit-as>
     <reload-on-as>256</reload-on-as>
     <reload-on-rss>192</reload-on-rss>
     <no-orphans/>
     <vacuum/>
     <lazy-apps/>
 </uwsgi>

It really seems strange to me that UWSGI kills that worker just after the request. When there is a request for some static files, there are new PIDs for each request.

This is not happening on mod_wsgi with Apache instance. The CPU spikes to 100% from time to time, but the average load is OK, 0.25, 0.22, 0.15 at the time of writing, and the RAM usage is about 300 out of 900 MB.

Can anyone point me to a right direction? Thanks

解决方案

Ran into this issue: uwsgi cheaper killing workers processing requests

Bug fixed & merged in August 2016.

https://github.com/unbit/uwsgi/issues/1288

https://github.com/unbit/uwsgi/commit/f5dd0b855d0d21be62534dc98375fae2cd7c13f0

这篇关于UWSGI杀死工人太快了的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
Python最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆