On Fri, Nov 19, 2010 at 12:50 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 11/18/2010 6:28 AM, Wolfgang Forstmeier wrote:
Hi List,
I cannot confirm the thoughts of Fabio, we have an Trac version internaly which just runs fine. It is not as slow as that Trac installation of Boost is.
I guess that is maybe something with Webserver/Python installation or an Plugin problem?!
Sure.. Do you have any suggestions as to what the problem is?
(Apologies for jumping in) Not really a suggestion, but a question: have we configured Trac to use an RDBMS backing store, or are we still using SQLite to handle the massive number of tickets we have on there?
We don't have that many plugins installed: The base Trac plugins, IniAdmin, SpamFilter, and XMLRPC (unused for now I think). Python is 2.6.something running with WSGI (I don't think mod_python is an option for the OSL admins).
I think we're running into IO issues with SQLite being the main source of contention. I cannot confirm this remotely though, but I do think it may be worth looking into moving the tickets out of a SQLite store into a MySQL server -- so that at least we're able to tune the MySQL configuration independent of Trac. Usually, high system loads mean that there are a lot of active processes on average on the system. This can mean that the subversion processes spawned along with the Trac usage (maybe someone's spidering Trac, like Google/Microsoft) through the web is causing the high system loads. If CPU utilization is not that high I'm willing to bet that we're running into the IO bounds of the server svn.boost.org is hosted on. Just a guess though, I can help with some investigation when I get some free time. HTH -- Dean Michael Berris deanberris.com