Some how WSGI and/or mod_python develop memory leak.
If you seen your memory & swap space all taken up by Apache that load WSGI and / or mod_python you might try this work around :
Set MaxRequestsPerChild in apache2 conf to some number instead of 0 (zero).
In my case I set MaxRequestsPerChild to 3 due to the Apache is quite fast to take the memory.
Search for all MaxRequestsPerChild directives, you might be found it at multiple places.
Update : Please read the comment from the creator of mod_wsgi below .
2 comments:
The mod_python module has known memory leaks, especially triggered by constant Apache restarts. The mod_wsgi module doesn't have this issue, although Python itself does have some memory leaks where it is destroyed and then recreated within the same process. Obviously though, if you use mod_wsgi, whether the combination has memory leaks is meaningless if you are still loading mod_python into Apache when not used. You should use mod_wsgi in isolation. Also read 'http://blog.dscpl.com.au/2009/11/save-on-memory-with-modwsgi-30.html', which goes into detail of how you can also avoid the memory leaks in Python itself.
In general, using MaxRequestsPerChild is not recommended because of other problems it can cause. For embedded mode this relates to issues described in 'http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html'. That post might even in itself explain some of the real issues causing your problem.. Setting MaxRequestsPerChild to a really low value like you have is also a bad idea because of the performance impacts it has.
In short, use mod_wsgi daemon mode and use the lazy initialisation feature in that blog post and you shouldn't have issues. If you do, it is likely to be a problem with your Python web application and not mod_wsgi.
Hi Graham,
Thank you for your great explanation.
We'll try your recipe.
Thank you again.
Post a Comment