django and memory usage
issya
start up apache and access my web site, it seems that the apache
process then takes up an additional 20m of ram. This memory does not
ever get freed up. My virtual host setup is below.
KeepAlive Off
<VirtualHost *>
ServerName www.findatenant.com
ServerAlias *findatenant.com
WSGIDaemonProcess findatenant user=bob group=bob processes=1
threads=10 maximum-requests=100
WSGIProcessGroup findatenant
WSGIScriptAlias / /home/bob/findatenant.com/findatenantfast.wsgi
</VirtualHost>
If I try to add the inactivity-timeout argument to the daemonprocess,
apache tells me "Invalid option to WSGI daemon process definition"
upon startup.
I guess I have a few questions here.
1. Why does it not free up the memory?
2. What am I doing wrong that my daemon process line cannot look like
this?
WSGIDaemonProcess findatenant user=bob group=bob processes=1
threads=10 maximum-requests=100 inactivity-timeout=300
3. If the inactivity-timeout did work for me or it reached the 100
maximum requests and a user is logged in, do they loose their session?
4. I was also messing around with adding additional things to the
apache config detailed below. Are these things necessary or even
useful with the mod_wsgi options I have set.
In an ideal world I would like the processes to free up the memory
without messing with people on the site. It would be nice if they went
back down right after people were finished with the site. But I would
also like it to do a sort of reset once a week.
issya
question.
4. I was also messing around with adding additional things to the
apache config detailed below. Are these things necessary or even
useful with the mod_wsgi options I have set.
ServerLimit 2
Graham Dumpleton
>
> I am running mod_wsgi in daemon mode with apache worker mpm. Once I
> start up apache and access my web site, it seems that the apache
> process then takes up an additional 20m of ram. This memory does not
> ever get freed up.
Once Django application starts to be accessed, it is normal for
process memory footprint to go up. This is because with Python web
applications any Python modules, application code and application data
are cached in memory between requests. This is in contrast to PHP
which tries to throw away everything between requests. How much memory
is used depends on complexity of the application.
> My virtual host setup is below.
>
> KeepAlive Off
>
> <VirtualHost *>
>
> ServerName www.findatenant.com
> ServerAlias *findatenant.com
>
> WSGIDaemonProcess findatenant user=bob group=bob processes=1
> threads=10 maximum-requests=100
> WSGIProcessGroup findatenant
>
> WSGIScriptAlias / /home/bob/findatenant.com/findatenantfast.wsgi
>
> </VirtualHost>
>
> If I try to add the inactivity-timeout argument to the daemonprocess,
> apache tells me "Invalid option to WSGI daemon process definition"
> upon startup.
Then you aren't using mod_wsgi 2.X, but must be using older mod_wsgi
1.X. Ensure you are using latest mod_wsgi 2.3.
> I guess I have a few questions here.
>
> 1. Why does it not free up the memory?
>
> 2. What am I doing wrong that my daemon process line cannot look like
> this?
> WSGIDaemonProcess findatenant user=bob group=bob processes=1
> threads=10 maximum-requests=100 inactivity-timeout=300
These answered above.
> 3. If the inactivity-timeout did work for me or it reached the 100
> maximum requests and a user is logged in, do they loose their session?
Most Python web applications store session information in a separate
database, not in memory. This is actually necessary to support
multiprocess web servers. So, no they shouldn't loose their active
session in this situation.
Graham
Graham Dumpleton
>
> Sorry, forgot to add the extra apache options for my number 4
> question.
>
> 4. I was also messing around with adding additional things to the
> apache config detailed below. Are these things necessary or even
> useful with the mod_wsgi options I have set.
>
> MaxRequestsPerChild 100
If running WSGI application in daemon mode, this option has no effect
on WSGI application. This is because it only affects normal Apache
worker processes which are serving static files and proxying requests
to WSGI application in daemon process.
> ServerLimit 2
This limits number of Apache worker processes serving static files or
proxying requests through to WSGI application in daemon process. For
Apache worker MPM with default 25 threads per worker process, a server
limit of 2 may be reasonable for small to medium size sites or on a
memory constrained VPS.
Graham
issya
As always, thank you for your help. You are correct that it was an
earlier version of mod_wsgi. I assumed the latest version of Ubuntu
would carry a later version of mod_wsgi.
Is putting the maximum-request and inactivity-timeout the correct
approach to ensuring processes do not grow too large? Or would it be
better to just let it handle themselves?
I have a basic django app with mostly generic views and it only has 1
custom view. I ran Apache Benchmark on it to try and flood it out. The
processes ended up taking all of the memory up and wouldn't let it go.
On Oct 9, 10:06 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
Graham Dumpleton
>
> Graham,
>
> As always, thank you for your help. You are correct that it was an
> earlier version of mod_wsgi. I assumed the latest version of Ubuntu
> would carry a later version of mod_wsgi.
>
> Is putting the maximum-request and inactivity-timeout the correct
> approach to ensuring processes do not grow too large? Or would it be
> better to just let it handle themselves?
If you have a site which will be infrequently accessed, then using
inactivity-timeout will help in dropping memory usage back down when
application not being used.
The maximum-request option will help where you have a problem with
memory usage increasing for some reason, or if for some reason you had
to run Django with Debug enable for some reason. Will make sure that
your process doesn't keep growing and growing in size.
So yes, both a good idea if you are concerned about keeping memory
usage in check.
Graham
issya
this is more related to Apache. Beack to the ServerLimit option. I
currently have 2 sites with the configuration I posted in my first
post. Say I have 10 sites with minimal traffic, would it still be good
to do ServerLimit 2? Or would I change that as my number of sites goes
up?
Also I have 4 apache processes running at startup. If each site uses 1
process, what are the other 2? Should they be there?
Thanks again
On Oct 9, 10:50 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
Graham Dumpleton
>
> Thank you for the tips. I have a couple of more questions, although
> this is more related to Apache. Beack to the ServerLimit option. I
> currently have 2 sites with the configuration I posted in my first
> post. Say I have 10 sites with minimal traffic, would it still be good
> to do ServerLimit 2? Or would I change that as my number of sites goes
> up?
>
> Also I have 4 apache processes running at startup. If each site uses 1
> process, what are the other 2? Should they be there?
What you have is one Apache parent process. This is effectively the
process monitor for Apache and is what spawns of Apache child worker
process. The mod_wsgi code in the Apache parent is also responsible
for spawning off the mod_wsgi daemon process. You would then have 2
Apache child worker processes with ServerLimit of 2 and with that
number of processes being started initially as well. Finally you have
the mod_wsgi daemon process. Under 'top' or 'ps', the mod_wsgi daemon
process will still show as a apache/httpd process. If you use the
display-name option (mod_wsgi 2.X) with WSGIDaemonProcess, you can
override what the name of the mod_wsgi daemon process appears as when
using the 'ps' command (but not 'top').
As to whether 2 Apache worker processes is sufficient as you add
sites. If they are running default 25 threads per process, that is 50
concurrent requests you can handle. You configuration for mod_wsgi
daemon has 10 threads, so 10 concurrent requests. Thus, as is those 2
Apache worker processes are more than sufficient in the sense that it
has more capacity than the daemon process does. Must remember though
that the Apache worker processes also handle static requests as well
though.
As you add more sites or sites become more used, you just need to keep
an eye on the amount of traffic they receive and how many concurrent
requests they receive. It is that that will dictate whether you need
to add more Apache worker processes, or start running with multiple
processes in a daemon process guide.
Overall, if you aren't expecting to handle more than 5-10 concurrent
requests for each application at the same time, what you have would be
okay, just scale things up if traffic requirements become more than
that.
Graham
issya
understand how this works, I think I need to learn a lot more about
it.
On Oct 10, 2:10 am, "Graham Dumpleton" <graham.dumple...@gmail.com>