From: Date: July 3 2008 10:25pm
Subject: Re: mutex contention for the query cache
List-Archive: http://lists.mysql.com/internals/35794
Message-Id: <486D35CC.1040300@presence-pc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I've just done the test, and search indeed also happen with mysql 
configured in DEMAND mode.

   Jocelyn

Rick James a écrit :
> 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=rjames@stripped
>>
>>
>