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

On Tuesday 09 May 2006 03:42, Kris Kennaway wrote:
> On Tue, May 09, 2006 at 03:34:59AM +0300, Sven Petai wrote:
> > > Hmm, with this patch mysql 4.1 seems to crash at startup.  I haven't
> > > yet had time to investigate.  Is anyone else seeing this?
> >
> > Seems to run fine here with 4.1.18 on amd64, but doesn't seem to make
> > much difference though.
> >
> > I ran the tests again on the 8 core machine with and without rwatsons
> > patch and this time with 6 tests for each setting and generated graphs:
> > http://bsd.ee/~hadara/debug/mysql4/stats.html
> >
> > thr + select smack dynamics with the patch really do look quite
> > interesting
> >
> > PS
> > I'm currently running testround with rwatsons patch +
> > http://people.freebsd.org/~csjp/kern_descrip.c.1145074052.diff  + mysqld
> > change davidxu suggested.
> > Are there any other patches out there that I should try ?
>
> Sorry, I meant
> http://people.freebsd.org/~csjp/sys.mpsafe.fileops.1145896495.diff
> instead of that patch.  Also try turning down HZ to 100, and changing
> the wakeup()s to wakeup_one() in sys/filedesc.h.

I preformed additional tests with the settings you suggested,
updated graphs are available _at_
http://bsd.ee/~hadara/debug/mysql4/stats.html

 * with rwatsons patch + mysqld change suggested by davidxu +
   http://people.freebsd.org/~csjp/sys.mpsafe.fileops.1145896495.diff
  there doesnt seem to be much difference, but in general things seem to be 
couple of percent better
  mutex profiles for this configuration are available _at_
  with 10 smack threads: 
http://bsd.ee/~hadara/debug/mysql4/freebsd_cur_ps2/mutex_freebsd_cur2_p2-select_10_10000.txt
  with 100 smack threads: 
http://bsd.ee/~hadara/debug/mysql4/freebsd_cur_ps2/mutex_freebsd_cur_p2-select_100_1000.txt

 * second run was with same patches, but HZ set to 100
  this helps performance a lot but creates large fluxuations in select results 
with >20 threads + thr, sometimes difference between 2 runs with same 
settings was 10000+ q/s

I'm currently still testing wakeup() -> wakeup_one() suggestion.

In addition I did full testrun on linux to see how much this hardware
is really capable of... graphs for that are available on the stats page too.