One other question along these lines...
We've got ServerLimit and MaxClients set to the same number. Does ServerLimit
affect mod_wsgi at all? i.e. is perhaps apr_proc_fork is failing? (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.
Alec
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.
