Date: Fri, 17 Jun 2005 10:38:34 -0400 From: David Sze <dsze@alumni.uwaterloo.ca> To: freebsd-stable@freebsd.org Subject: Re: FreeBSD MySQL still WAY slower than Linux Message-ID: <6.2.1.2.2.20050617103807.058c6fa8@mail.distrust.net>
next in thread | raw e-mail | index | archive | help
At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All:
>Thank you all for your suggestions on this thread, here's a brief
>breakdown of most of the ideas from people:
>
>Billy Newsom: COMPILER, DISK, MYSQLVERSION
>Daniel Eischen: +/-HTT, Thread scopes
>Greg Lehey: MALLOC
>Guy Helmer: PREEMPTIVE, vfs.read_max
>Jon Dama: David Xu's Thrds, Ptmalloc, cpu affinity, sched+hwcacheing
>Kris Kennaway: +/-HTT
>Robert Watson: Thread scopes, LIBTHR/Linuxthr on 5 and 6?, LOCKING,
> HTT, SMP/UP
>Thomas Hurst: FreeBSD-current, Don't overload mysql!
>Vladimir Chukharev: COMPILEOPTS, TABLETYPES
>Xin Li: PROFILE, HTT insignificant
>
>The bad news is that I've not managed to get very far at all lately as
>MySQL has been crashing too much to even stop and test stuff
>elsewhere.
>
>The good news though, is that the Mysql folks have agreed to setup
>tests to profile mysql on identical hardware running FreeBSD and Linux
>with an aim to find out exactly where the problem really is. They
>reckon they'll spend at least two weeks trying to find out why Linux
>is so much faster - if they do this right I'd be surprised if we can't
>improve things quite a lot.
>
>Also, it'd be good if any of you who still have an interest in this
>could add any ideas or suggestions that may help *them* with their
>testing. If so, just get in touch with me asap before they get too
>stuck into anything that might prove fruitless.
>
>Here's hoping we can get MySQL running as well on FreeBSD as it ought
>to.
I just spent a couple days comparing MySQL 4.1 performance on:
FreeBSD/amd64 5.4-RELEASE (libpthread, system and process scope)
FreeBSD/amd64 6.0-CURRENT (libpthread, libthr, system and process
scope)
CentOS/amd64 4.0 (i.e. RHEL4.0)
I couldn't get libthr to work on FreeBSD/amd64 5.4-RELEASE, mysqld would
immediately coredump and the stacktrace looked like it was corrupted (i.e.
hundreds of stack frames, all of which were ???).
This was the hardware:
Dell PowerEdge 2850
Dual Xeon 3.6GHz EMT64, HTT disabled
4GB RAM
amr RAID controller w/256MB battery backed cache
5 x 73GB 15K RPM SCSI disks configured as one RAID5 w/64KB stripe
I was seeing the same sort of super-smack numbers that everyone's been
reporting, i.e. that Linux box was twice as fast as FreeBSD.
It turns out that the problem was the same thing everyone usually points
the finger at, but no one actually mentioned this time: Linux mounts its
partitions async by default. I don't have the exact numbers in front of me
right now, but these were the ballpark figures (I'm not going to separate
out results for all of the different threading libraries for FreeBSD
because the deltas weren't huge):
super-smack select-key
5.4-RELEASE ~20,000 queries/second
6.0-CURRENT ~24,000 queries/second
CentOS w/async ~36,000 queries/second
CentOS w/sync ~26,000 queries/second
super-smack update-select
5.4-RELEASE ~4,000 queries/second
6.0-CURRENT ~4,500 queries/second
CentOS w/async ~7,500 queries/second
CentOS w/sync ~750 queries/second
That last CentOS number is not a typo, it was an order of magnitude
slower. I didn't try other file systems on CentOS, just the default
ext3. It's possible that reiserfs or xfs might not be as affected by
switching from async to sync.
So my production server is now happily running mysql 4.1 on 6.0-CURRENT :).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.1.2.2.20050617103807.058c6fa8>