From: Date: August 2 2008 11:24am Subject: Re: mutex contention for the query cache List-Archive: http://lists.mysql.com/internals/35849 Message-Id: <489427DB.4080007@mysql.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MARK CALLAGHAN wrote: > On Fri, Jul 4, 2008 at 11:31 AM, Brian Aker wrote: >> Hi! >> >> On Jul 4, 2008, at 7:44 AM, MARK CALLAGHAN wrote: >> >>> I fear that some of the hardware we are to be offered won't meet the >>> needs of the software we have deployed and we will all end up buying >> If you end up with multi-core board with multi-processors, if you can >> disable cores you can get a bit more performance. Crazy? Yeah, but it >> happens to be where the main branch is today. > > There is a Stonebraker research project on an OLTP engine called > H-store that partitions data so that one core gets each partition. > Locking is not an issue at that point. MySQL Cluster could approximate > that deployment model. interestingly enough, our ndbmtd version 2 already uses that model. advertising: goal for it to be functional end of august and usable by end of the year fyi 1: ndbmtd is multi-threaded variant of ndbd fyi 2: we already have a ndbmtd version 1, that currently use 3 threads and approx. 2 cores fyi 3: ndbmtd version 2, will be able to utilize 6 threads, and hopefully approx. 6 cores fyi 4: how a future version 3 will look like is not yet determined, we will first evaluate how version 2 performs... but the 2 "big" alternatives are roughly 1) increase 6 to a bigger number, but keep the 1-thread only operates on a subset of data 2) allow several threads to operated on same data, introducing ordinary locks fyi on current ndbmtd internals: - threads communicate internally using messages (like it does distributed) - all messages are passed using single-reader-single-writer fifo-queues, i.e *no* locks /jonas