By Alan Hargreaves-Oracle on Nov 20, 2007
I've had a few cases recently that have brought this issue to the fore.
It's amazing how many people think that the answer to all performance issues is to simply throw more cpu at the problem.
Let's work through this thought (and this holds true for other queuing type locks too).
- On Solaris, if the mutex holder is on proc, the waiter spins instead of blocking and sleeping
- If we have sufficient threads wanting the same mutex, we can quickly utilize all cpus in a box
- The more threads we have in the queue for a mutex, logically the longer any given thread will take to progress through this queue to obtain it.
What does this tell you about what is likely to happen if you add more cpus into the mix?
It's relatively obvious now, isn't it.
- More cpus stuck spinning in kernel space
- Longer mutex queues
- Longer average time to obtain mutex for each thread that wants it.
The obvious consequence being that adding more cpus can actually have the effect of making the problem worse.