From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1G948j-0000k6-7g for garchives@archives.gentoo.org; Fri, 04 Aug 2006 18:11:17 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k74IAKAp029822; Fri, 4 Aug 2006 18:10:20 GMT Received: from popmail.jettissystems.com (popmail.jettissystems.com [38.118.146.212]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k74I7nA2021311 for ; Fri, 4 Aug 2006 18:07:49 GMT Received: from [10.23.0.100] (c-67-188-43-202.hsd1.ca.comcast.net [67.188.43.202]) by popmail.jettissystems.com (Postfix) with ESMTP id 30C7B56D486 for ; Fri, 4 Aug 2006 11:07:46 -0700 (PDT) Message-ID: <44D38CF0.9010909@badapple.net> Date: Fri, 04 Aug 2006 11:07:44 -0700 From: kashani User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Monthly Gentoo Council Reminder for August References: <20060801093001.C97C864465@smtp.gentoo.org> <44D1BFFD.4040303@gentoo.org> <1154607828.23292.5.camel@localhost> <44D1F4EF.3000209@gentoo.org> <1154612153.17538.26.camel@onyx> <44D30BE8.8060909@gentoo.org> <44D34753.6090604@gentoo.org> <44D36D6E.3060705@gentoo.org> In-Reply-To: <44D36D6E.3060705@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 0730263f-d043-424f-91bc-a7eb055231a8 X-Archives-Hash: 152584687561b23f0debafc00a02be50 Joshua Jackson wrote: > Here's the question, gnome's bugzilla has over twice as many bugs as > we have, is quite speedy and doesn't seem to suffer from the OOM > killers that our bugzilla has. So what's the difference? Did gnome > just toss hardware at the problem to make it go away or have they done > something to make bugzilla work for them? > > I think throwing hardware at the problem is the wrong approach in this > case, as its just delaying the problem that has made the new hardware > seem like the solution...which will no doubt creep up again. > > Don't get me wrong, the donation of hardware from gni is greatly > appreciated. I'd just to see that we try and see why we have the > problem in the first place as well. As I'm sure that this problem will > creep up again Another technique is to change high transaction tables to Innodb table format. Innodb is going to be roughly 30% slower than MyISAM for selects and take up much more space on disk approx 3-5x larger. However it has row locking which solves the contention issue. A good example of mixed table types is actually Mediawiki which uses Memory for hitcounters, Innodb for pages and revisions, and MyISAM for everything else. Bugzilla has 50 tables in its schema, but converting bugs and bugs_activity to Innodb might cause more problems than it solves. Normally a decision to change tables format is accompanied by some normalization of your tables and changing queries to get the best performance out of each table type. It's possible that changing a few tables would work and have no downside, but if that were the case I'd expect upstream to have suggested it. Here's a paper on general Mysql scaling that's pretty interesting and easy to read if you don't have much db background. http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf kashani -- gentoo-dev@gentoo.org mailing list