Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets )

From: Scott Long <scottl_at_samsco.org>
Date: Tue, 09 May 2006 19:38:38 -0600
Sven Petai wrote:

> On Tuesday 09 May 2006 20:35, Julian Elischer wrote:
> 
>>Sven Petai wrote:
>>
>>are there any patches that take the gettimeofday() calls and replace
>>them with something that is cheap
>>such as only doing every 10th one and just returning the last value ++ 1
>>uSec for the other ones..
>>
>>a ktrace of Mysql shows a LOT of gettimeofday() calls.
>>
> 
> 
> well I have actually done that although in a very hackish way that
> is suitable *only* for benchmarking, but my goal really was
> just to find out if gettimeofday really is the bottleneck.
> 
> Basically I just preloaded my version of "buffering" time() over libc's.
> That function asked kernel for time only after every 5000 invocations.
> I could get away with that for benchmarking since
> about 99,99% of gettimeofday() calls from mysqld really come through
> time() which has anyway only 1 second resolution and mysqld seems to use
> the value for purposes that are not really all that critical, like
> stats and safeguard timers.
> It's also called far more than 5000 times in a second while benchmark is
> running so it should return correct values too.
> 
> Anyway, the results really astonished me, what I got for reducing
> gettimeofday() calls by ~96% was performance *decrease* of about 4-5%.
> I thought something was wrong with my measurement techniques, so I
> wrote the buffering time() function that used TSC directly into mysqld,
> replaced all the time() calls with that, so that number of gettimeofday()
> syscalls ktrace reported was down to only the initial one, but still got the 
> same 5% decrease.
> 
> I just can't explain it, but can't find any mistakes in methods too.
> 
> The library I used is available _at_
> http://bsd.ee/~hadara/debug/mysql4/time_lib_hack.c

Were you testing on SMP, and if so, was Hyperthreading enabled?

Scott
Received on Tue May 09 2006 - 23:38:48 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:55 UTC