On 20/12/2014, at 2:14 PM, Christopher Pollati <[email protected]> wrote:
> On Monday, December 15, 2014 9:06:46 PM UTC-5, Graham Dumpleton wrote: > > On 16/12/2014, at 12:51 PM, Christopher Pollati <[email protected]> wrote: > >> I'm using a build of Apache 2.27 Prefork (based on instructions from >> DIYMacServer.com) on Mac OS 10.9, Python 2.7.5, and mod_wsgi 4.2.4. I had a >> similar setup at one point with OS 10.6 and mod_wsgi 3.5, however, with the >> new step up it sometimes feels like the Trac pages are slower to respond. I >> also notice in Activity Monitor it shows a process of httpd will hit 100% >> and hover around that for a few minutes even after the Trac page has >> rendered and been served. >> >> I am hosting 2 domains, each with it's own projects in Trac. Each domain has >> a separate trac.wsgi script: (where "vhost" is substituted with the domain) >> >> import sys >> sys.stdout = sys.stderr >> >> import os >> os.environ[ 'TRAC_ENV_PARENT_DIR' ] = "/Base/trac/projects/vhost" >> os.environ[ 'PYTHON_EGG_CACHE' ] = "/Base/trac/egg-cache/vhost" >> os.environ[ 'TRAC_ENV_INDEX_TEMPLATE' ] = >> "/Base/trac/templates/vhost/projects.html" >> >> import trac.web.main >> >> application = trac.web.main.dispatch_request >> >> >> And in each VirtualHost Apache config, I set up the WSGI options like this >> (again substituting "vhost" with the domain): >> >> WSGIScriptAlias / /Base/trac/cgi-bin/vhost/trac.wsgi >> WSGIProcessGroup trac-vhost >> WSGIApplicationGroup %{GLOBAL} >> WSGIPassAuthorization On >> >> Are there any suggestions on how to improve the server from being maxed out >> or changes that I should make to either the wsgi script or Apache configs? > > What is the WSGIDaemonProcess directive set to that you should also have for > each? > > If you are not already doing so, add to the WSGIDaemonProcess directive the > option: > > display-name=%{GROUP} > > You can then use 'ps auxwww' to see processes and the daemon process group > process will be labelled differently to 'httpd' and you can verify better > that it is the process with Trac running in them which is going out of > control. > > Graham > > > Ah! I just checked, looks like one of them had the WSGIDaemonProcess > directive commented. So I changed them to this: > > WSGIDaemonProcess trac-domain user=_www group=_www processes=3 threads=32 > display-name=%{GROUP} > > and it looks like the Tracs are more responsive and the CPU usage isn't > staying at 100% for long. That would imply you had the WSGIProcessGroup directive commented out as well, because if the WSGIProcessGroup was still in place and referencing trac-domain, which was commented out, you should have got an error on each request. Anyway, having it not use daemon mode would have been bad, especially if using prefork MPM in Apache. That is because you would have had many more copies of Trac in memory and you would have incurred the startup cost of each. Worse is that because Trac is slow to start up, Apache can get itself confused and create many more processes than needed, due to it thinking it sill hasn't got enough processes to handle request but issue is that processes are slow to start. In worst case it can get into a bit of a death spiral and create so many it overwhelms the system. Worse is that in embedded mode Apache will then start killing off processes when it thinks it doesn't need them, so you would likely see this continual churn of Trac instances being created and destroyed which would cause a lot of CPU usage. I talk about this issue in one of my talks at PyCon. http://lanyrd.com/2013/pycon/scdyzk/ 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 http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
