Re: GNOME Bugzilla Upgrade: Test Upgrade On Friday?
- From: Owen Taylor <otaylor redhat com>
- To: Max Kanat-Alexander <mkanat everythingsolved com>
- Cc: gnome-infrastructure gnome org, bugmaster gnome org
- Subject: Re: GNOME Bugzilla Upgrade: Test Upgrade On Friday?
- Date: Tue, 28 Jul 2009 20:30:21 -0400
On Tue, 2009-07-28 at 16:07 -0700, Max Kanat-Alexander wrote:
> Owen Taylor wrote:
> > I think our main method of getting high performance is going to have
> > almost everything in memory - the entire bugzilla.gnome.org database
> > after 9 years and 0.5M bugs is still only 8GB.
>
> For sure. It's still nice to have good disks for times when MySQL can't
> do things in RAM, though. (It will still occasionally spool enormous
> temp tables to the disk.)
>
> > Presumably for the table-lock-avoidance purposes of shadowdb you could
> > just have two databases on the same MySQL instance.
>
> Bugzilla no longer uses table locks, so that's not really a problem. I
> don't think we'd see a significant-enough advantage by having two DBs on
> the same machine, for modern Bugzillas. If performance suffers we could
> try it, but I think we should try setting up Bugzilla without the slave,
> first.
Ah, I was assuming that the reason you were suggesting a split was the
classic one. If the table locks problem is solved, then I think we can
certainly start with the simple configuration.
After all, we're *almost* managing to do OK for performance today with
vastly underpowered server, table locks, and no shadowdb. (*)
> > (So given only one machine the question becomes: is it better to do that
> > with MyISAM tables, or to use InnoDB tables that have row locks and
> > shouldn't need shadowdb. But have other overheads and might suffer from
> > bugzilla not demarcating transactions.)
>
> Bugzilla itself already makes this decision for us, so we don't have to
> worry about it.
>
> > I think my basic instinct is the same as yours - to just set up drawable
> > directly as a single big mysqld server instead of virtualizing within
> > it. I'd certainly like input from others. I'm neither a DB expert not a
> > virtualization expert,
>
> I wouldn't say that I'm a MySQL wizard, but I have enough experience
> setting up Bugzilla installations that I'm fairly sure of my
> recommendations.
>
> > and I'm hoping someone else will do most of the
> > setup anyways :-)
>
> I'm capable of doing as much of the setup as required, if I can get the
> necessary access to the machine. Otherwise I can guide anybody who has
> the necessary access.
Because of the way we manage things we can't really give you root access
to just one machine. So I think the two logical options are:
A) We start from the RHEL mysql configuration, manage modified
config files with puppet, create databases, and give you access
at the database level.
B) We create a bugzilla user, give you access to that, set up
specialized start and stop scripts to run a mysql instance
as that user, and at the system level only put in the
necessary hooks to get the start script run at boot time.
I have a preference toward A), because it avoids creating special
knowledge for this particular situation that sysadmins will have to
learn about. If we can make it just a normal MySQL server setup, then
once someone understands puppet, they will be immediately able to go in
and do stuff.
(And we'll have version control for the config changes.)
- Owen
(*) Some people may object to this characterization, because there are
times when everything is really slow, and there are other times when
everything gets blocked up entirely for 10 minutes. But for most of the
day, we respond to simple queries almost instantly.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]