Thank you for very comprehensive answer. I will correct configuration soon, and let you know how that worked out.
Best regards, Bartosz On Tue, Nov 3, 2009 at 1:05 AM, Graham Dumpleton <[email protected]> wrote: > > > > On Nov 3, 12:48 am, Bartosz Broda <[email protected]> wrote: >> >> I looked there, but the only relevant thing I found concerning >> >> multiple instances of Trac was to run all of the instances in one >> >> python interpreter. But to tell the truth I didn't have enough time to >> >> read modwsgi wiki in depth :( >> >> > Huh, it actually talks about it being preferable to use daemon mode >> > and run different Trac instances in their own process groups for >> > various reasons. That is, the opposite of what you are talking about. >> >> Sorry, I was trying to set up the Trac as fast as possible, because >> other matters were more important at the moment :(. >> >> > It is certainly a bad idea to to run multiple Trac instances in same >> > interpreter where not the same code base, different versions of >> > plugins, or dependent modules or where need distinct Python egg cache >> > directories for projects. Also should be avoided if relying on >> > os.environ for setting Trac location. >> >> Only one thing is different among the configurations: a svn >> repository. Probably that caused all the problems... > > Different subversion repositories I don't think would be the issue. > Normally Trac would handle that fine. > > Looking at your configuration again, the mistake is that you are > using: > > WSGIScriptAlias /trac/PROJECT /var/trac/PROJECT/eggs/cgi-bin/ > trac.wsgi > > <Directory /var/trac/PROJECT/htdocs> > WSGIApplicationGroup %{GLOBAL} > Order deny,allow > Allow from all > </Directory> > > There are two issues with this. > > The first is that the WSGIApplicationGroup directive isn't being used > in the first place so you aren't even using the main interpreter and > thus will definitely have Python subversion wrappers breaking > unpredictably. It would also have caused a separate copy in memory for > each Trac, using much more memory and bloating out Apache sizes. This > could cause whole system to slow down. > > The reason it isn't being used is because the path for Directory > doesn't match where the WSGI script file is. It should have been: > > WSGIScriptAlias /trac/PROJECT /var/trac/PROJECT/eggs/cgi-bin/ > trac.wsgi > > <Directory /var/trac/PROJECT/eggs/cgi-bin> > WSGIApplicationGroup %{GLOBAL} > Order deny,allow > Allow from all > </Directory> > > Note that have changed path for Directory directive. > > The second issue is how Apache is even able to serve up the WSGI file > from that location given that there is no Allow directive for that > directory because of Directory not matching. Looks like the security > of your Apache installation is lax in some other area in allowing > access to parts of the file system it shouldn't without being > specific. > >> > The Python egg cache is a particular problem in your code as you >> > change it on every request and that could screw up badly on a >> > multithreaded configuration. >> >> > So, that particular auto generated trac.wsgi from trac-admin is >> > actually a bit dangerous. Normally one should not be setting Python >> > egg cache directory like that. It should be set once only. >> >> Thanks for pointing that out. I will try to adjust my configuration >> accordingly. > > I would suggest you use the configuration on mod_wsgi site of: > > WSGIDaemonProcess sites user=trac group=trac processes=3 threads=25 > python-eggs=/var/trac/eggs > WSGIScriptAlias /trac /var/trac/apache/trac.wsgi > > <Directory /var/trac/apache> > WSGIProcessGroup sites > WSGIApplicationGroup %{GLOBAL} > SetEnv trac.env_parent_dir /var/trac > Order deny,allow > Allow from all > </Directory> > > That is, a single WSGI script file rather than many. With that single > WSGI script file being in /var/trac/apache. > > Also, a single Python eggs directory specifed by python-eggs option to > WSGIDaemonProcess and at /var/trac/eggs. > > Make sure eggs directory exists and writable to user that daemon > process runs as or that Apache runs as. Drop the user/group options > and/or set them appropriately depending on what user you want to run > Trac as. If options left off, then will run as Apache user. > > Note that have used trac.env_parent_dir method for configuration so > that Trac knows that location is parent directory of many Trac sites. > So, read up in Trac documentation about what that is all about. > >> Maybe that info should be posted onhttp://trac.edgewall.org/wiki/TracModWSGI >> too? > > There are more than ample configurations in what is on the mod_wsgi > site. > >> Do you think that bad performance could be caused by this egg cache >> misconfiguration? As I told before - mod_python seems to work way >> faster then mod_wsgi. > > In summary your problems are: > > 1. WSGIApplicationGroup was being ignored because Directory path > didn't match where WSGI script file was installed. This would cause > subversion errors. > > 2. Lax security in Apache to allow WSGI script file in that location > to work without specific Allow directory. > > 3. Because of (1), separate interpreter used for each Trac and so lots > more memory. Plus you were using embedded mode, so will encounter > problems described in: > > http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html > > That is why it would have behaved worse than mod_python. Ie., > misconfigured. > > 4. Not using a single Python egg directory. This wouldn't have been an > issue in end as each Trac was using different interpreter. Still bad > to change egg cache variable on every request. > > 5. Not using feature of Trac to manage lot of Apache sites and instead > treating them as separate. > > Anyway, have to run now, but that should give you something to think > about. > > Graham > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
