My mind is playing "Suffering Succotash..."
I have been working on MySQL performance for a while now, and the team
I am in have discovered that SysBench could do with a couple of tweaks
To simulate multiple users sending requests to a database, sysbench
uses multiple threads. This leads to two issues we have identified
with SysBench on Solaris, namely:
Neither of these issues are necessarily relevant only to Solaris, by the way.
Luckily there are simple solutions. We can fix the random() issue by
using lrand48() - in effect a drop-in replacement. Then we can fix the
memory allocator by simply choosing to link with a better allocator on
To help with a decision on memory allocator, I ran a few simple tests
to check the performance of the two best-known scalable allocators
available in Solaris. Here are the results ("libc" is the default
To see the differences more clearly, lets do a relative comparison, using "umem" (A.K.A. libumem) as the reference:
So - around 20% less throughput at 16 or 32 threads. Very little difference at 1 thread, too (where the default memory allocator should be the one with the lowest synchronization overhead).
Where you see another big difference is CPU cost per transaction:
I will just point out two other reasons why I would recommend libumem:
I have logged these two issues as sysbench bugs: