On 18 March 2010 06:07, Alec Flett <[email protected]> wrote:
> One other question along these lines...
> We've got ServerLimit and MaxClients set to the same number.
A default configuration of Apache doesn't usually set ServerLimit and
instead the builtin default would be used.
The Apache documentation specifically says that 'special care' should
be taken when playing with ServerLimit.
The last MPM settings I saw you post were:
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 600
MaxClients 600
MaxRequestsPerChild 1000
Although you increased ServerLimit per documentation due to increasing
MaxClients above 256, I would question why you need such an
excessively high value for MaxClients.
The small range of spare servers and low maximum requests per child is
also troubling as this would potentially cause a great deal of
recycling/destruction of processes.
If all the prefork processes are doing is serving static files and
proxying to daemon mode, this configuration looks way over the top to
me.
What is your justification for setting MaxClients to such a high value?
For a properly tuned web application, request response times should be
well under a second. A high value for MaxClients would only be
justified if you have lots of long running requests or if keep alive
connections become an issue. For keep alive connections if they become
an issue, you would be better off turning keep alive off or putting
nginx proxy in front. The nginx proxy would also serve to isolate you
from slow clients as well, further removing the need for a high value
of MaxClients. Default Apache installations would normally have
MaxClients more than 150 and that would handle the majority of web
sites.
Have you ever used mod_status or other monitoring to find out what the
maximum number of prefork processes are being created? Are you really
getting hundreds of processes to justify that excessive value?
Tell me again how many daemon process groups you are creating and how
many processes/threads are allocated across them.
> Does
> ServerLimit affect mod_wsgi at all?
It shouldn't as doesn't control anything that mod_wsgi relies on.
> i.e. is perhaps apr_proc_fork is
> failing?
Shouldn't, all I can see ServerLimit controlling is amount of memory
allocated in the scoreboard files used to communicate information
between Apache server child process and parent process. The mod_wsgi
daemon processes don't use the scoreboard and even closes the
scoreboard handles so user applications cant fiddle with it.
> (Though I'd expect to see "Couldn't spawn process" messages...)
> Also, I'm setting application-group to '%{GLOBAL}' but I do have different
> process groups, each with different python-paths. I guess I'm a little
> confused about application-group vs process-group, and maybe this is just a
> red herring.
Application groups refer to the Python sub interpreter within a
process. A value of %{GLOBAL} refers to the main or first interpreter
created. It has special attributes. If you are only delegating one
WSGI application to a daemon process, it is safe to force use of main
interpreter in all daemon processes.
So, as long as only one Django instance across each daemon process
group, not an issue.
Graham
>
> On Mar 17, 2010, at 11:19 AM, Alec Flett wrote:
>
> On Mar 1, 2010, at 5:39 PM, Graham Dumpleton wrote:
>
> BTW, I have never seen you post about what version of Apache you are
> using, nor what operating system/distribution you are using.
>
>
> Sorry just getting back from a long vacation. So to answer the easy
> questions:
> - Gentoo 1.12.11.1 (though we are switching to Fedora literally today, so
> we'll see if this problem goes away)
> - Apache config on Gentoo:
> Server version: Apache/2.2.9 (Unix)
> Server built: Jan 15 2009 18:47:53
> Server's Module Magic Number: 20051115:15
> Server loaded: APR 1.3.2, APR-Util 1.3.2
> Compiled using: APR 1.3.2, APR-Util 1.3.2
> Architecture: 64-bit
> Server MPM: Prefork
> threaded: no
> forked: yes (variable process count)
>
> - Apache config on Fedora 11
> Server version: Apache/2.2.11 (Unix)
> Server built: Mar 17 2009 09:15:07
> Server's Module Magic Number: 20051115:21
> Server loaded: APR 1.3.3, APR-Util 1.3.4
> Compiled using: APR 1.3.3, APR-Util 1.3.4
> Architecture: 64-bit
> Server MPM: Prefork
> threaded: no
> forked: yes (variable process count)
> One thing we noticed was that it says "Threaded: no" - now obviously that's
> how prefork works, but do we need threading somehow enabled in APR?
> I did address most of the issues you talked about before - i.e.
> WSGIRestrictEmbedded, upping the debug level, etc. I'll post more of what
> you asked for in the next few days.
>
> More below.
>
>
> Thanks for all that explanation - this definitely clears up quite a bit for
> me as far as how mod_wsgi actually functions under the hood!
>
> If you are not handling dynamic requests of any form in the Apache
> server child processes, be it PHP, Python, Perl etc, then there is
> generally no reason to set MaxRequestsPerChild to anything but 0. If
> Apache is as such only handling static file serving and/or proxying to
> mod_wsgi daemon processes, then worker MPM would be much better choice
> than prefork as have mentioned before.
>
> Similarly, unless you have issues with resource leakage in your Python
> application, I wouldn't use maximum-requests to WSGIDaemonProcess
> either. For a site with large amount of traffic, would certainly be
> cautious about setting it to to low a value, ie., 1000, if it could be
> causing processes to be recycled within a matter of seconds.
>
>
> this is really great advice - it fits with my intuition, but I wasn't
> trusting my intuition :)
> I didn't see these specific guidelines anywhere on the Google Code wiki,
> I'd definitely recommend putting them up there!
> Alec
>
> Graham
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
