> On 9 Feb 2016, at 6:37 PM, Anurag Srivastava <[email protected]> wrote:
>
> Hi,
>
> I have an application written in Django and we are using Apache + mod_wsgi
> combination for the server. Intermittently, we notice high Load Average
> (monitored using htop) and the application freezes. We are using daemon mode
> in wsgi. I have played around with the number of processes and number of
> threads configuration but have not been able to zero in. The application
> usage is mostly on Django admin and there are 25-30 concurrent users on it. I
> don't see any issue on the memory front but the CPU runs at 100% when we
> notice the slowness. It is not like the queries are poorly written as the
> same requests take 400-500 milliseconds to complete when the server is
> running fine.
>
> Not sure what is going wrong. Could you please guide?
>
> Here is the configuration
>
> <VirtualHost *:80>
> WSGIScriptAlias / /var/www/bigstylist/wsgi.py
>
> DocumentRoot /var/www/bigstylist
>
> ServerName tools.bigstylist.com
> Alias /static /var/www/bigstylist/GUI/static/
>
> WSGIDaemonProcess bigstylist processes=5 threads=5 display-name=%{GROUP}
> python-path=/var/www/bigstylist
> WSGIProcessGroup bigstylist
>
> <Directory /var/www/bigstylist/>
> Require all granted
> </Directory>
>
> </VirtualHost>
Consider watching:
http://pyvideo.org/video/4049/using-benchmarks-to-understand-how-wsgi-servers-w
<http://pyvideo.org/video/4049/using-benchmarks-to-understand-how-wsgi-servers-w>
A possible problem one can encounter because of the Python global interpreter
lock (GIL) is that if you have CPU intensive tasks running in different threads
of the same process, the performance will degrade.
What I would suggest is that the admin interface be delegated to a separate
daemon process group where they use single threaded processes. See if that
improves things.
<VirtualHost *:80>
ServerName tools.bigstylist.com <http://tools.bigstylist.com/>
# XXX This is bad. You should not set DocumentRoot to be a parent directory of
where you project code is.
DocumentRoot /var/www/bigstylist
Alias /static /var/www/bigstylist/GUI/static/
WSGIDaemonProcess bigstylist processes=5 threads=5 display-name=%{GROUP}
python-path=/var/www/bigstylist
WSGIDaemonProcess bigstylist-admin processes=5 threads=1 display-name=%{GROUP}
python-path=/var/www/bigstylist
WSGIScriptAlias / /var/www/bigstylist/wsgi.py
WSGIProcessGroup bigstylist
WSGIApplicationGroup %{GLOBAL}
<Location /admin>
WSGIProcessGroup bigstylist
</Location>
<Directory /var/www/bigstylist/>
Require all granted
</Directory>
</VirtualHost>
Also read:
http://blog.dscpl.com.au/2014/02/vertically-partitioning-python-web.html
<http://blog.dscpl.com.au/2014/02/vertically-partitioning-python-web.html>
Once have that going, you might go further and create a new daemon process
group which you then delegate specific admin URLs as a way to try and isolate
what is the worst performer. I have seen various people complaining over the
years about how the admin interface has been a source of bad performance.
Down the track, if I ever merge in all my performance monitoring stuff for
mod_wsgi into the main branch, then it also could be used to track down the
issue. The data from that talk above was obtained using the performance
monitoring feature of mod_wsgi I was working on.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
