| 1 |
Chris Bainbridge wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> On 03/08/06, Lance Albertson <ramereth@g.o> wrote: |
| 5 |
>> You have no concept of where the bottle neck is. The webserver hosting |
| 6 |
>> the cgi part isn't being loaded hardly at all. The database server is a |
| 7 |
>> pretty beefy box, and again, its not so much a specific hardware |
| 8 |
>> limitation, just more a limitation on the design of bugzilla and its |
| 9 |
>> ties to mysql. We're having to 'fix' the problem by getting a |
| 10 |
>> master/slave mysql db server setup which the OSL didn't have setup at |
| 11 |
>> the time. This is apparently the 'solution' upstream suggests which I |
| 12 |
>> think is daft, but its what we have to do. |
| 13 |
> |
| 14 |
> I'm curious what the problem is with bugzilla and it's db |
| 15 |
> interactions? You're suggesting a specific issue rather than general |
| 16 |
> db performance issues like fs, io scheduling, raid1, hyperthreads, |
| 17 |
> etc.? |
| 18 |
|
| 19 |
Mostly dealing with table locking and how bugzilla handles most of its |
| 20 |
queries. If you want more details, look for r2d2, Kingtaco, or jforman |
| 21 |
(in that order). Another issue was backups were locking up all the |
| 22 |
tables, so for a matter of an hour or more every day, bugs was just |
| 23 |
useless because of that. Upstream's 'solution' was to use a db cluster |
| 24 |
and make the backup on the read-only side. Anyways, I personally don't |
| 25 |
know a lot of the details, but feel free to ask those people mentioned |
| 26 |
above. |
| 27 |
|
| 28 |
-- |
| 29 |
Lance Albertson <ramereth@g.o> |
| 30 |
Gentoo Infrastructure | Operations Manager |
| 31 |
|
| 32 |
--- |
| 33 |
GPG Public Key: <http://www.ramereth.net/lance.asc> |
| 34 |
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 |
| 35 |
|
| 36 |
ramereth/irc.freenode.net |
Archives