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
-~----------~----~----~----~------~----~------~--~---

Reply via email to