Thank Graham very helpful info, We are using Django, version 6410 with a couple patches applied and we are currently using mod_wsgi in embedded mode.
I tried using the WSGIImportScript before and if I remember right it seemed to load up the python interpreter and a few modules but no the brunt of django. It may be because my import script that I was pointing to was just my django.wsgi file which just set up the path and environs and then consisted of import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler() Am I right in assuming I would also need to import the brunt of the modules I was intending to use either directly or indirectly, or should I have a separate import script for this? On Oct 20, 4:05 pm, "Graham Dumpleton" <[EMAIL PROTECTED]> wrote: > 2008/10/21 Yish <[EMAIL PROTECTED]>: > > > > > I've been looking through the mod_wsgi website and this group to see > > if there are any strategies for dealing with apache processes that > > have grown too large (memory leaks) and here is what I believe is the > > current state of affairs. > > > A) Fix the memory leaks (Haven't found the cause yet for us but over > > the course of 20K requests to a single machine about 5-10 of our 60 > > httpd processes will have jumped from using just under 30 megs to over > > 100 megs. Of course I am still trying to find the issue but in the > > meantime need a solution to prevent my machine from swapping like > > crazy) > > What Python web framework (if any) are you using and what version of > that framework? > > > B) Set maximum requests to a small number. This will reduce the > > duration taht a process is around for reducing the number of these > > bloated processes that should exist simultaneously. > > Good start, just make sure you use right configuration method based on > whether embedded mode or daemon mode used. > > > C) Write a shell/python script to kill the bad processes. This isn't a > > bad option but I am wondering what is the best method to kill an httpd > > process without affecting our users. E.g. if sent a kill -9 to the > > process while it was handling the request, a user would experience an > > error. Is there a way to prevent this from happening? > > For Apache child worker processes, what Apache does itself is send a > SIGTERM every second until process exits, but if it doesn't exist > after 3 seconds it sends a SIGKILL. > > For mod_wsgi daemon mode, a SIGTERM should cause daemon process to > initiate a monitored orderly shutdown and the process itself will > SIGKILL itself if shutdown timeout expires and it hasn't exited. The > shutdown timeout defaults to 5 seconds. > > > D) Graham has talked about adding some functionality ala perls > > SizeLimit to set a maximum RSS size limit for a process. There seems > > to be some issues with this approach and it currently looks like the > > project is on hold. > > Apparently doesn't work on Linux. > > > My questions is am I missing something and/or do others have a > > preferred approach? > > > In regards to B or C, I currently prime all my httpd instances after > > they have been spawned (using httpperf) to make sure that the python > > interpreter, Django and all other modules have been loaded to prevent > > latency for the first user to hit that process. Does anyone know if > > there is a way to do that with mod_wsgi when a new process is created > > using options B or C? > > You can use WSGIImportScript to designate script file to be loaded on > process start, thus preloading your code. Point it at same WSGI script > file as WSGIScriptAlias, however, you will need to manually use > WSGIProcessGroup/WSGIApplication group in appropriate context to say > where WSGIScriptAlias is executed as you need to say where it is for > WSGIImportScript and it has to match. > > Search for WSGIImportScript in documentation and past mailing list messages. > > 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 -~----------~----~----~----~------~----~------~--~---
