2009/9/17 Simon Meers <[email protected]>:
> I have a dozen or so Django-powered sites running in a modwsgi setup using
> two WSGIProcessGroups (depending on the timezone required -- UTC/local).
> This is working very well -- thank you :)
>
> I discovered an issue yesterday however, when I began doing some image
> processing using PIL -- one of the processes jumped from using 30MB to 150MB
> of RAM. It does not appear to be a memory leak as such, and does not
> increase much beyond this with repetition, but just loading the relevant
> libraries, etc. This would be fine except that I have so far existed very
> happily running all these sites from within my modest 80MB (RAM) WebFaction
> account, and hogging this much RAM for too long will cause my processes to
> be killed (and rightly so).
>
> This morning I discovered the handy maximum-requests and inactivity-timeout
> WSGIDaemonProcess options, which do a pretty good job of ensuring that the
> processes get restarted regularly enough to avoid being killed.
>
> However I'm wondering if there is a better way of handling this; rather than
> waiting for inactivity or a certain number of requests, it would be nice to
> be able to cleanly restart the process when the resource usage breached a
> predefined threshold.
Although UNIX environments have setrlimit() and can specify
RLIMIT_DATA/RLIMIT_AS/RLIMIT_RSS to control memory available, there is
not way of having a signal be sent to the process when some soft limit
is exceeded such that process could be restarted like one can get with
RLIMIT_CPU. What is therefore required is some sort of separate
background task, either thread or external process, that can somehow
determine when memory limit is reached and for that to generate the
signal. Problem is that there is no portable way of finding out how
much memory is used from within a process using system C APIs. Thus
why I don't provide such an inbuilt feature.
> I could not find any such option in the documentation;
> I don't think that stack-size is quite what I'm after? I could run a cron
> job to monitor the RAM usage and issue apache stop/start commands, but this
> seems to lead to a brief period of "Service Temporarily Unavailable" status
> during the process.
You are getting "Service Temporarily Unavailable" because you are
stopping/starting whole of Apache.
If you are using 'ps' to work out how memory used, then ensure you are
using display-name option to WSGIDaemonProcess with argument
'%{GROUP}'. This will result in 'ps' process list showing:
(wsgi:groupname)
where groupname is name given as first argument to WSGIDaemonProcess
You can then look for any WSGI daemon process and if over your defined
limit, send it a SIGTERM signal using kill command. That will cause
the WSGI daemon process to be restarted without affecting main Apache
processes. You wouldn't then expect to see the "Service Temporarily
Unavailable" as main Apache processes will have effect of queuing up
the requests until WSGI daemon process ready to handle them again.
> The image processing tasks are performed occasionally by administrators, not
> during general use of the site.
>
> Any suggestions?
Except for above, can only suggest having another WSGIDaemonProcess
group and delegate just the URLs which are only occasionally used and
which cause transient memory usage spike, and then set more aggressive
maximum-requests and inactivity-timeout on just those URLs. For
example:
WSGIDaemonProcess main
WSGIDaemonProcess bloat maximum-requests=100 inactivity-timeout=20
WSGIScriptAlias / /some/path/application.wsgi
WSGIProcessGroup main
<Location /memory/hungry/url>
WSGIProcessGroup bloat
</Location>
In other words, partition a single Django instance across multiple
daemon process group based on subset of URLs.
> Also, is there a way of seeing a memory usage breakdown to pinpoint problem
> areas?
Not really.
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
-~----------~----~----~----~------~----~------~--~---
