一个wsgi应用程序吃掉所有apache客户端

时间:2012-09-21 10:00:26

标签: python apache mod-wsgi

我们有一个SOAP mod_wsgi(apache)应用程序,它有时会负载很重。相同的Apache服务器一些其他wsgi-apps。不幸的是,您只能在服务器级别设置MaxClients,而不是每个wsgi-app。

我们得到:

server reached MaxClients setting, consider raising the MaxClients setting

有没有办法阻止这个wsgi应用程序吃掉所有apache worker?

我想仅将503“Service Unavailable”返回给连接到SOAP wsgi app的SOAP客户端。

Apache config snippet:

   WSGIDaemonProcess soap_app threads=1 processes=3
   WSGIScriptAlias /soap_app /home/soap_app/django_wsgi.py
   <Location "/soap_app/">
       WSGIProcessGroup soap_app
       WSGIApplicationGroup %{GLOBAL}
   </Location>

soap应用程序只有3个wsgi守护程序进程。但它占据了更多的阿帕奇工人。

更新 我们使用apache prefork mpm。有阿帕奇工人。而对于mod_wsgi,我们也使用prefork。有M个mod_wsgi工作进程。可以通过MaxClients控制apache worker count。 mod_wsgi工作者计数由上面的配置控制。

我认为你无法在python wsgi app(django)中处理这个问题。我想它需要通过mod_wsgi或apache config来完成。

以下是mod_status的第一行:

  Server Version: Apache/2.2.17 (Linux/SUSE) mod_ssl/2.2.17 OpenSSL/1.0.0c
  mod_wsgi/3.3 Python/2.7
  Server Built: 2011-07-26 13:43:36.000000000 +0000
===============================================================================
  Current Time: Thursday, 20-Sep-2012 13:15:11 CEST
  Restart Time: Thursday, 06-Sep-2012 16:30:45 CEST
  Parent Server Generation: 0
  Server uptime: 13 days 20 hours 44 minutes 25 seconds
  Total accesses: 307471 - Total Traffic: 7.7 GB
  CPU Usage: u11.85 s1.56 cu0 cs0 - .00112% CPU load
  .257 requests/sec - 6.8 kB/second - 26.4 kB/request
  127 requests currently being processed, 13 idle workers
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWKWWWWW_WWWWWKWWWWWWWWW_WWWWWW_WW_WWWWWWK._WW
W__WW__._W_W__........
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process
Srv  PID   Acc   M CPU  SS   Req  Conn  Child Slot   Client         VHost     Request
0-0  15135 0/27/ W 0.04 8417 0    0.0   0.37  290.12 10.1.1.1       foohost   POST /soap_app/foo HTTP/1.1
           11553
           0/
1-0  15142 125/  W 0.18 7354 0    0.0   2.48  324.82 10.1.1.1       foohost   POST /soap_app/foo HTTP/1.1
           12475
           0/
2-0  18350 157/  W 0.27 4780 0    0.0   4.84  300.09 10.1.1.1       foohost   POST /soap_app/foo HTTP/1.1
           11249
3-0  20112 0/10/ W 0.02 7106 0    0.0   0.29  315.77 10.1.1.1       foohost   POST /soap_app/foo HTTP/1.1
           12714
4-0  16562 0/35/ W 0.07 7853 0    0.0   0.96  328.98 10.1.1.1       foohost   POST /soap_app/foo HTTP/1.1
           12098
5-0  20152 0/25/ W 0.06 6732 0    0.0   0.71  288.17 10.1.1.1       foohost   POST /soap_app/foo HTTP/1.1

1 个答案:

答案 0 :(得分:1)

所有请求都由Apache子级(由MaxClients控制)提供,但每次请求命中soap_app url时,Apache子级都将等待3个WSGIDaemonProcess中的一个。如果您收到soap_app的请求的速度超过了您通过3个进程提供的速度,那么最终您将耗尽Apache的孩子。

我看到控制专用于soap_app的Apache子数的唯一方法是使用mod_proxy并将soap_app请求代理到另一个“服务”。 proxy pass directive允许您定义要服务的并发请求数,该数量将等于您要用于soap_app的Apache子级数。

soap_app请求提供服务的“服务”可能是同一个Apache的另一个VirtualHost(从未测试过)或带有soap_app应用程序的gunicorn实例