Hello,
I have recently been examining a very simple mysql workload using
sysbench on an 8way opteron system. I have been doing this for the
purpose of optimizing contention and scheduling in the FreeBSD kernel. As
part of this I discovered the scaling problem with futexes that has been
fixed in recent linux kernels. You can read some about this in my blog at
jeffr-tech.livejournal.com.
I'm writing to offer my assistance and observations from this experience.
I unfortunately do not have a lot of time to test or aid in your
development. However, I do have some comments about your locking
mechanisms that might be useful.
Firstly, has anyone examined using pthread standard locks in place of your
home-rolled spinlocks? These cause a serious priority inversion problem
at high loads. I observe that the number of yields goes up dramatically
as the number of threads exceeds the number of cpus. The source of this
problem is that lock owners are likely to have worse priorities than lock
spinners in many cases. This causes us to schedule the owners behind
those spinning and waiting for the lock.
On FreeBSD the umtx code that backs pthread locks is priority aware and
very fast with low contention. At higher contention we'll at least be
running the correct threads. I am not a database expert however and I
don't understand how these things are deployed. If you can restrict the
number of threads to equal the number of cpus in the system this is not a
problem in practice.
I understand there are some scalability efforts underway. I would be
interested in hearing about your plans and how you go about this.
Cheers,
Jeff
