RE: mutex contention for the query cache

[Rick James]

What happens with DEMAND (2)?  Does it _always_ check the cache?  Or is it smart enough to
postpone deciding whether to check until after the parse?  The bug seemed to be focused on
the ON case.

The in-house recommendation here is to set it to DEMAND, then use SQL_CACHE where desired
(which is infrequent).  Might we be better off with OFF?  Especially on multi-core boxes?

 
Rick James
MySQL Geeks - Consulting & Review

 

> -----Original Message-----
> From: Jocelyn Fournier [mailto:joc@stripped] 
> Sent: Thursday, July 03, 2008 12:44 PM
> To: MARK CALLAGHAN
> Cc: internals@stripped
> Subject: Re: mutex contention for the query cache
> 
> And what is also frustrating is because of the current 
> implementation of 
> the qcache, you can't use SQL_NO_CACHE keyword to skip this 
> search, and 
> only use the qcache when it really makes sense (see 
> http://bugs.mysql.com/bug.php?id=37416).
> 
>    Jocelyn
> 
> MARK CALLAGHAN a écrit :
> > The query cache has a mutex that is locked while it is 
> searched. This
> > is not a spin lock, so many threads will go to sleep when there is
> > contention. And it is made worse because work is done to create the
> > search key in Query_cache::send_result_to_client() (work == memory
> > allocation and other byte copying) after the mutex is locked.
> > 
> > Are there plans to fix this?
> > I don't have benchmark results (yet), but I am willing to bet that
> > this is a problem.
> > 
> 
> -- 
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:    
> http://lists.mysql.com/internals?unsub=1
> 
>