On Aug 11, 9:08 am, Jumpfroggy <rocketmonk...@gmail.com> wrote:
> On Aug 10, 2:24 pm, dartdog <tombran...@gmail.com> wrote:
>
> > Big help!! Had just started getting using too much memory notices from
> > Webfaction yesterday evening...
>
> Yeah, I didn't even pay attention till I hit about 120-140MB on my
> 80MB plan and got everything turned off.  Otherwise I would have just
> let it grow, not paying attention.
>
> > The other item is using the crontab -e command from ssh to comment out
> > apps you don't need to have running.... For some reason could not find
> > that when I was looking for it and one of my sites just kept
> > restarting after .stop, which I understand but did not know how to
> > stop the behavior!
>
> Good catch!  I noticed that they restart themselves, didn't bother
> finding out why.
>
> Here's my complete writeup and 
> howto:http://forum.webfaction.com/viewtopic.php?pid=11096
>
> Thanks to those in this thread for helping me make this work.

FWIW, WebFaction is providing mod_wsgi 2.5 now. Got mail from Remi
about it today.

A few other comments about your post on WebFaction forums.

Don't use 'processes=1' with WSGIDaemonProcess directive. The default
is one process anyway, and using 'processes' option has side effect of
setting wsgi.multiprocess to be true even if there is only one
process. Yes, it may seem odd, but it is done that way to allow
multiprocess to be flagged as true when using a cluster of machines
with only one process on each server.

When inactivity timeout expires, Django is technically restarted, it
is actually shutdown. Although a new daemon process is started, that
process isn't preloaded with anything and so is effectively an empty
process. This is why on next request it has to load Django again. That
is, lazily loads Django only when known it is required.

I now understand what you meant about supervisor process. Though you
were talking about separate supervisord application. :-(

Only other thing is something I think I said before. That is that
MinSpareThreads and MaxSpareThreads only make sense when multiples of
ThreadsPerChild. This is because the number of threads in a process is
fixed, it will not shutdown or start up threads within a process.
These values are there used to govern number of active processes
between limits as set down by StartServers and MaxClients/
ThreadsPerChild. In other words, granularity is actually at process
level and not thread level.

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