read-write SQL performance
Abdullah Ibn Hamad Al-Marri
almarrie at gmail.com
Sat Aug 4 20:44:48 UTC 2007
On 8/4/07, Kris Kennaway <kris at obsecurity.org> wrote:
> I did some benchmarking of sysbench in read-write mode (previous tests
> have focused on read-only mode). The reason for this is that the disk
> hardware in my 8-core test system is slow (single disk) and is too
> easily saturated. In fact mysql and pgsql have identical performance
> when writing to disk. In other words, I seem to be mostly
> benchmarking the disk performance and not database or kernel
> Faster disk hardware is necessary to explore database performance
> differences or kernel bottlenecks. An upper bound on possible
> read-write performance comes from using a memory disk instead of
> physical disk hardware. I replicated the databases onto a suitably
> large (2gb) tmpfs and reran the tests together with some mutex
> Results are here:
> There are a couple of interesting features.
> mysql has better peak performance than pgsql, but then quickly falls
> in the toilet. Profiling indicates that at peak there is some
> contention on lockmgr locks and the proc lock, but most of the
> contention is in userland (i.e. within mysql itself). At higher loads
> the bottleneck is overwhelmingly within mysql (and the system is
> actually 90-100% idle). This seems to be a serious scaling problem
> within mysql.
> Peak pgsql performance is lower than mysql, but there is comparatively
> little degradation at higher loads. Profiling shows that the dominant
> bottleneck at all workloads is lockmgr.
> Fortunately there is a lockmgr rewrite in progress by Attilio for SoC,
> so there is great scope for performance improvements to pgsql.
> Significant mysql performance improvements may require fundamental
> architectural work by the mysql developers.
Maybe Greg would be interested in the MySQL issues?
-Abdullah Ibn Hamad Al-Marri
More information about the freebsd-performance