| 1 |
> |
| 2 |
> Here's the question, gnome's bugzilla has over twice as many bugs as |
| 3 |
> we have, is quite speedy and doesn't seem to suffer from the OOM |
| 4 |
> killers that our bugzilla has. So what's the difference? Did gnome |
| 5 |
> just toss hardware at the problem to make it go away or have they done |
| 6 |
> something to make bugzilla work for them? |
| 7 |
> |
| 8 |
> I think throwing hardware at the problem is the wrong approach in this |
| 9 |
> case, as its just delaying the problem that has made the new hardware |
| 10 |
> seem like the solution...which will no doubt creep up again. |
| 11 |
> |
| 12 |
|
| 13 |
Because it's not just "more hardware" it's "search queries execute on |
| 14 |
read-only slaves and write queries execute on the master" which is a |
| 15 |
design change from how things are done now. If you give bugs a massive |
| 16 |
search query it can lock a bunch of tables in the current system, which |
| 17 |
means all those people who are trying to commit stuff to bugs will |
| 18 |
probably sit waiting for the massive search query to finish ;) Now |
| 19 |
multiply by a few times since tons of people use our bugzilla and you |
| 20 |
can imagine this happening quite often. |
| 21 |
|
| 22 |
In the new system the massive search query will run on the slave system, |
| 23 |
and it won't affect people making changes; hoewever there may be soem |
| 24 |
delay between data replication from the master to the slave(s), but that |
| 25 |
would be implementation dependent (depends on what you use to replicate). |
| 26 |
-- |
| 27 |
gentoo-dev@g.o mailing list |
Archives