Boost logo

Boost :

Subject: Re: [boost] [trac] slow
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-11-18 12:02:56

On Fri, Nov 19, 2010 at 12:50 AM, Rene Rivera <grafikrobot_at_[hidden]> 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 is
hosted on.

Just a guess though, I can help with some investigation when I get
some free time.


Dean Michael Berris

Boost list run by bdawes at, gregod at, cpdaniel at, john at