On 15 April 2011 07:09, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
> On 15 April 2011 06:35, Carl Nobile <carl.nob...@gmail.com> wrote:
>> It looks like you are running a single process with 50 threads, I think you
>> should use more processes with less threads something like this:
>>
>> WSGIDaemonProcess site-1 user=django group=django processes=5 threads=10
>> maximum-requests=1000
>> WSGIProcessGroup site-1
>> WSGIScriptAlias / /somepath/django.wsgi /somepath/django.wsgi
>>
>> The 'maximum-requests=1000' will kill each thread after a 1000 requests and
>> create a new one, this helps to keep memory leaks to a minimum.
>
> Sorry to correct you Carl, but that isn't quite how it works.
The small correction is that once that number of threads is reached
for the whole process, irrespective of how many threads are running in
the process, then the process as a whole is killed off and restarted.
It isn't done at individual thread level within ongoing process.
The maximum-requests option should be avoided in production processes
if at all possible because the quicker requests come through the more
frequently the process will restart, which is likely the last thing
you want to happen when under load.
As to number of processes/threads, as Carl pointed out, OP should
avoid having high numbers of threads in a single process and instead
create multiple processes with a small number of threads.
For most people, the default of 15 threads per process is likely
overkill with that many concurrent requests never actually occurring,
so increasing it with no good reason is not a good idea. If you have
the memory available, possibly better off going to 3 processes each
with 5 threads only.
Graham
> I'll respond in more detail later to original question. Still 7am here
> and just got off phone from a work meeting. So need to wake up a bit
> more first. :-)
>
> Graham
>
>> ~Carl
>>
>> On Thu, Apr 14, 2011 at 3:18 PM, Chase <chase.seib...@gmail.com> wrote:
>>>
>>> I have a custom Django app that's becoming unresponsive
>>> intermittently. About once every couple of days between three servers,
>>> serving about 10,000 requests a day. When it happens, it never
>>> recovers. I can leave it there for hours, and it will not server any
>>> more requests.
>>>
>>>
>>> In the apache logs, I see see the following:
>>>
>>> Apr 13 11:45:07 www3 apache2[27590]: **successful view render here**
>>> ...
>>> Apr 13 11:47:11 www3 apache2[24032]: [error] server is within
>>> MinSpareThreads of MaxClients, consider raising the MaxClients setting
>>> Apr 13 11:47:43 www3 apache2[24032]: [error] server reached MaxClients
>>> setting, consider raising the MaxClients setting
>>> ...
>>> Apr 13 11:50:34 www3 apache2[27617]: [error] [client 10.177.0.204]
>>> Script timed out before returning headers: django.wsgi
>>> (repeated 100 times, exactly)
>>>
>>>
>>> I am running:
>>>
>>> apache version 2.2, using the worker MPM
>>> wsgi version 2.8
>>> SELinux NOT installed
>>> lxml package being used, infrequently
>>> Ubuntu 10.04
>>>
>>>
>>> apache config:
>>>
>>> WSGIDaemonProcess site-1 user=django group=django threads=50
>>> WSGIProcessGroup site-1
>>> WSGIScriptAlias / /somepath/django.wsgi /somepath/django.wsgi
>>>
>>>
>>> wsgi config:
>>>
>>> import os, sys
>>> sys.path.append('/home/django')
>>> os.environ['DJANGO_SETTINGS_MODULE'] = 'myapp.settings'
>>> import django.core.handlers.wsgi
>>> application = django.core.handlers.wsgi.WSGIHandler()
>>>
>>>
>>> When this happens, I can kill the wsgi process and the server will
>>> recover.
>>>
>>> >ps aux|grep django # process is running as user "django"
>>> django 27590 5.3 17.4 908024 178760 ? Sl Apr12 76:09 /usr/
>>> sbin/apache2 -k start
>>> >kill -9 27590
>>>
>>>
>>> This leads me to believe that the problem is a known issue:
>>>
>>> "(deadlock-timeout) Defines the maximum number of seconds allowed to
>>> pass before the daemon process is shutdown and restarted after a
>>> potential deadlock on the Python GIL has been detected. The default is
>>> 300 seconds. This option exists to combat the problem of a daemon
>>> process freezing as the result of a rouge Python C extension module
>>> which doesn't properly release the Python GIL when entering into a
>>> blocking or long running operation."
>>>
>>>
>>> However, I'm not sure why this condition is not clearing
>>> automatically. I do see that the script timeout occurs exactly 5
>>> minutes after the last successful page render, so the deadlock-timeout
>>> is getting triggered. But it does not actually kill the process.
>>>
>>> I'm thinking of switching to MPM/prefork, but I'm not sure if that
>>> should have any effect, given that I'm in daemon mode already.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "modwsgi" group.
>>> To post to this group, send email to modwsgi@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> modwsgi+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/modwsgi?hl=en.
>>>
>>
>>
>>
>> --
>> -------------------------------------------------------------------------------
>> Carl J. Nobile (Software Engineer)
>> carl.nob...@gmail.com
>> -------------------------------------------------------------------------------
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "modwsgi" group.
>> To post to this group, send email to modwsgi@googlegroups.com.
>> To unsubscribe from this group, send email to
>> modwsgi+unsubscr...@googlegroups.com.
>> 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 modwsgi@googlegroups.com.
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
