Re: mutex contention for the query cache

[MARK CALLAGHAN]

On Thu, Jul 3, 2008 at 6:28 PM, Brian Aker <brian@stripped> wrote:
> Hi!
>
> On Jul 3, 2008, at 2:05 PM, Sergei Golubchik wrote:
>
>> extent query cache so that Maria would use exact visibility rules and
>> maximize cache using - all transactions that could see the entry would
>> see it, those that couldn't - wouldn't.
>
> Well I will look forward to seeing how you solve that for Maria.
>
>> Query cache as it's done now is dirt cheap (concurrency can be fixed).
>
> I have some big doubts that this is the case. I think you will find that the
> lock methods being deployed right now around RW are not going to scale on
> any of the hardware we are seeing deployed. As is you will find that the
> general rule of thumb today is to just get rid of it. For anyone wanting to
> make use of the hardware that they are deploying the only solution is to
> junk it.
>

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
Power hardware from IBM. I would love to start over on a new design
(no customers like me to deal with, no bugs), but all I want now is a
few changes: partition the query cache and MyISAM key cache so the one
big lock is replaced with N locks and then use a spin lock built on
top of pthread mutex rather than using pthread mutex directly.

It would also help to add contention statistics for all of the locks
at the MySQL level so a DBA could determine on which locks most
threads go to sleep when there are locks usually held for a short
duration. InnoDB has this and it is invaluable. A simple spin lock
built on top of pthread mutex is sufficient.

> Cheers,
>        -Brian
>
> --
> _______________________________________________________
> Brian "Krow" Aker, brian at tangent.org
> Seattle, Washington
> http://krow.net/                     <-- Me
> http://tangent.org/                <-- Software
> _______________________________________________________
> You can't grep a dead tree.
>
>
>
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:    http://lists.mysql.com/internals?unsub=1
>
>



-- 
Mark Callaghan
mdcallag@stripped