gpt4 book ai didi

python - 一个 wsgi 应用程序吞噬了所有 apache 客户端

转载 作者:太空宇宙 更新时间:2023-11-03 19:12:23 24 4
gpt4 key购买 nike

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

我们得到:

server reached MaxClients setting, consider raising the MaxClients setting

有没有办法阻止这个 wsgi 应用程序吃掉所有 apache 工作人员?

我只想将 503“服务不可用”返回给连接到 SOAP wsgi 应用程序的 SOAP 客户端。

Apache 配置片段:

   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 工作人员。

更新:我们使用 apache prefork mpm。有N个apache worker 。对于 mod_wsgi,我们也使用 prefork。有 M 个 mod_wsgi 工作进程。 apache 工作线程数可以由 MaxClients 控制。 mod_wsgi 工作线程数由上述配置控制。

我认为你无法在 python wsgi 应用程序(django)中处理这个问题。我想这需要通过 mod_wsgi 或 apache 配置来完成。

这是 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

最佳答案

所有请求均由 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(从未测试过)或 gunicorn带有soap_app应用程序的实例

关于python - 一个 wsgi 应用程序吞噬了所有 apache 客户端,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12528330/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com