Wow, lots of good feedback here. Thanks! On Aug 9, 6:17 pm, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > Replace use of mod_python with mod_wsgi.
I'm using mod_wsgi for everything already, forgot to say. When I researched, it seemed like the newer/better way to do django. > Ensure you use prefork MPM > for Apache and delegate Django instances to run in mod_wsgi daemon > mode process. > Sorry, meant to say 'worker' rather than 'prefork'. DO NOT USE > PREFORK. Hmmm, that was a bad stuff up. :-) I just started using the worker MPM for one of my apps. It didn't seem to give any performance or memory savings, since my app is so small/simple. I'll keep an eye on it for later. Using daemon mode gives me auto-reloading by touching the .wsgi file (yay), but it uses more memory. Instead of supervisor (3MB) and apache worker/WSGI/Django (16MB) processes, now I have supervisor (3MB), apache worker (3MB), and wsgi/django (15MB). Not a huge gain, but just a bit more. I'm willing to live with that for the auto- reloading benefit, however. > Having done that, you can use inactivity-timeout option > for mod_wsgi daemon processes to have the process restarted and > returned to low memory footprint idle process after no use for a > while. This is exactly what I wanted!!! It's funny how when I finally read the description for something, it matches exactly what I'm looking for. I just didn't know where to look. I just tried it, and yes my memory baloons up to 16MB, then comes back down later. The only strange thing is that I set it to 10s (very short) to test out, but it takes a while for the process to actually be reclaimed. If I put inactivity-timeout=10, then load the page, then close the browser, memory usage should be reclaimed in 10 seconds, right? It seems more like 1 minute wait, which is fine but strange to me. Maybe there's only polling at certain intervals (checks every 1 minute), so the resolution isn't that fine. Maybe it's dependent on the deadlock timeout? Don't know. > Note, just ensure you don't keep loading mod_python after having > switched to mod_wsgi as mod_python will still consume some extra > memory when not in use. Yeah, never touched mod_python, so no problem here. On Aug 10, 6:44 am, Dj Gilcrease <digitalx...@gmail.com> wrote: > I just went though this process on Webfaction as well, so here is my > apache conf, it might help... Thanks for the post, good to see another webfaction user here. It always helps to see other people's real-world configs, since examples usually leave out the key bits. On Aug 10, 10:25 am, Dj Gilcrease <digitalx...@gmail.com> wrote: > >> MaxRequestsPerChild 5000 > > Don't see much point for MaxRequestsPerChild. > This just restarts the child after 5k requests, which helps clear out > some memory on occasion (I am still trying to get rrd or something run > on on Webfaction so I can actually map memory usage over time, and > start tuning Apache to my actual usage needs better) I experimented with using this as a dumb alternative to inactivity- timeout. Set MaxRequestsPerChild to 1, means the WSGI process will restart after each HTTP request. Very slow, but gives immediate memory savings. Only viable if the MEDIA_URL is set to a separate, static server (which webfaction recommends and makes easy). However, inactivity-timeout is still better. > >> WSGIPythonOptimize 1 > > Am dubious that turning on optimisation helps and can cause problems > > if set to '2' as doc strings will be stripped. > I doubt it is much improvement, but I just turned it on as a test and > did read that 2 is a bad idea which is why I stuck with 1 I'd love to see some benchmarks for this config with real apps. The docs make sense... don't expect magic switches to help if you haven't optimized your code, so I really shouldn't even worry about this option yet. > >> <VirtualHost *> > >> ServerName demo.digitalxero.net > >> DocumentRoot /home/digitalxero/webapps/wsgi/demo > >> WSGIDaemonProcess demo.digitalxero.net threads=5 > >> maximum-requests=10000 inactivity-timeout=3600 > >> display-name=wsgi:demo_site > > > That is 1 hour for inactivity timeout. They possibly want something > > less than that. > > Ya, I picked an hour for starters and will drop it down or increase it > as my needs dictate (one I get something to monitory usage better then > guessing) Their default DJango installs are either mod_python or mod_wsgi. The mod_wsgi is embedded mode, and has no inactivity-timeout and is StartServers 2, so by default one Django app takes 3MB + 16MB + 16MB of memory (35MB) out of your allotted 80MB. That means only 2.5 django apps before you run out of memory. They have a "how to save memory with django" howto, but it doesn't have any of these settings. I'll try to send it updates, they'll probably appreciate it. > > If you application does leak Python objects due to inability to break > > reference count cycles, there shouldn't really be a need for maximum > > requests. How would we go about finding out if there are memory leaks? I'm just starting to get into server performance, so I really don't know where to start. I wonder, where would be the best place to put howto's on apache + django memory optimization? All these options are documented in various places (apache, wsgi, and django docs), but in searching I couldn't find a good howto for any of these (hence this thread). Webfaction seems too host-specific, so maybe it should go on the djangoproject.com site? Where's the django wiki?? Thanks again Graham & DJ, you've helped me find exactly what I was looking for (daemon mode + inactivity-timeout) and my memory usage is going way down. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---