We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks), we've been keeping up with stable because supposedly all these new fixes to threading will help us out here. We're trying to get FreeBSD to perform reasonably well, in comparison to Linux, or even what we should expect to see. We're getting about half the performance we get from gentoo on the same application (mysql). The discussion on the 'freebsd-threads' mailing list about a year ago seems to match our experiences nowadays pretty well: http://lists.freebsd.org/pipermail/freebsd-threads/2004-May/002002.html Nothing much seems to have changed, although lots of people claim that FreeBSD 5.x is now fine, it doesn't seem to be. Here's a rough breakdown of the sort of performance we're seeing, this is the default select-key super-smack but setup for innodb rather than myisam.> Using the simple 'select-key.smack' Super-Smack benchmark (50 clients > with 1000 runs each): > > OS CPUs Build Threading Kqueries/sec > ------------------------------------------------------------- > FreeBSD 1 Pro KSE 10.6 > FreeBSD 1 Pro libthr 10.6 > FreeBSD 2 Pro libthr 14.4 > FreeBSD 2 Source libthr 14.5 > FreeBSD 2 Source KSE/P (static) 15.7 > FreeBSD 2 Source KSE/P (dynamic) 15.8 > FreeBSD 2 Source KSE/S (dynamic) 15.8 > FreeBSD 2 Pro KSE 15.9 > FreeBSD 2 Source LinuxThreads 17.7 > Gentoo 2 Source NPTL 34.0 !! > > (KSE/P = KSE with Process Scope Threading, KSE/S = KSE with System > Scope Threading)And, here's the full set of results :> # FreeBSD 5.4-STABLE SMP, MySQL Pro 4.1.12, libkse > gid@lithium 27 0 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 2 0 15978.35 > select_index 100000 3 0 15908.00 > select_index 100000 6 0 15852.89 > select_index 100000 6 0 15888.05 > select_index 100000 5 0 15868.09 > > # FreeBSD 5.4-STABLE NON-SMP, MySQL Pro 4.1.12, libkse > gid@lithium 9 0 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 11 0 11846.17 > select_index 100000 7 0 10544.36 > select_index 100000 4 0 10615.13 > select_index 100000 5 0 10607.55 > select_index 100000 4 0 10640.58 > > # FreeBSD 5.4-STABLE SMP, MySQL Pro 4.1.12, libthr > gid@lithium 33 130 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > Select_index 100000 19 3 14412.10 > select_index 100000 11 3 14529.83 > select_index 100000 11 3 14489.03 > select_index 100000 12 3 14488.09 > select_index 100000 15 3 14495.77 > > # FreeBSD 5.4-STABLE NON-SMP, MySQL Pro 4.1.12, libthr > gid@lithium 11 0 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 7 0 10531.75 > select_index 100000 5 0 10673.64 > select_index 100000 24 2 11179.66 > select_index 100000 28 4 10675.24 > select_index 100000 27 4 10191.25 > > # FreeBSD 5.4-STABLE SMP, Hand-built 4.1.12, libthr (dynamic) > gid@lithium 4 0 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 13 3 14487.99 > select_index 100000 16 3 14460.64 > select_index 100000 11 3 14397.79 > select_index 100000 15 3 14503.39 > select_index 100000 11 3 14502.58 > > # FreeBSD 5.4-STABLE SMP, Hand-built 4.1.12, libkse process scope (dynamic) > gid@lithium 7 0 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 16 2 15813.88 > select_index 100000 14 1 15901.01 > select_index 100000 3 0 15870.71 > select_index 100000 14 0 15917.34 > select_index 100000 6 0 15357.74 > > # FreeBSD 5.4-STABLE SMP, Hand-built 4.1.12, libkse process scope (static) > gid@lithium 7 130 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 19 3 15836.35 > select_index 100000 22 2 15807.58 > select_index 100000 20 3 15782.74 > select_index 100000 21 3 15790.82 > select_index 100000 21 3 15724.96 > > # FreeBSD 5.4-STABLE SMP, Hand-built 4.1.12, libkse system scope (dynamic) > gid@lithium 7 0 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 22 0 15792.41 > select_index 100000 8 0 15718.67 > select_index 100000 4 0 15837.49 > select_index 100000 5 0 15834.15 > select_index 100000 3 0 15892.31 > > # FreeBSD 5.4-STABLE SMP, Hand-built 4.1.12, LinuxThreads > gid@lithium 3 0 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 2 0 17709.35 > select_index 100000 2 0 17701.14 > select_index 100000 1 0 17758.04 > select_index 100000 1 0 17829.17 > select_index 100000 9 0 17557.00 > > # Gentoo Linux 2005.0, Hand-built 4.1.12, NPTL > gid@unoctunium 1 0 % foreach f (1 2 3 4 5) {/data/supersmack-1.3/bin/super-smack select-key.smack 50 1000|grep select_index} > select_index 100000 0 0 34420.06 > select_index 100000 2 0 34034.52 > select_index 100000 4 0 33236.42 > select_index 100000 3 0 33210.14 > select_index 100000 1 0 34610.75Thanks in advance for anyone that has a clue on this, and has anyone figured out why FreeBSD is just so amazingly slow compared to Linux. (That's not meant as flamebait, it just is.) Steve Roome
On Fri, Jun 10, 2005 at 06:05:37PM +0100, Steve Roome wrote:> We're using mostly: > > 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005Show your kernel config etc. Kris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050610/3b91fa3d/attachment.bin
* Steve Roome (steve@lonres.com) wrote:> We're trying to get FreeBSD to perform reasonably well, in comparison > to Linux, or even what we should expect to see. We're getting about > half the performance we get from gentoo on the same application > (mysql).Fancy giving CURRENT a try? For the record, we run FreeBSD 5.3 in production as our master database server without problems, so long as we keep the few heavy queries we do off it: Uptime: 6044357 Threads: 146 Questions: 1963912006 Slow queries: 1842 Opens: 182277 Flush tables: 3733 Open tables: 357 Queries per second avg: 324.917 But it would be nice not to fall back on Linux for our slaves to do the heavy lifting. Maybe FreeBSD 6 will be less disappointing in this regard. -- Thomas 'Freaky' Hurst http://hur.st/
Steve Roome wrote:>We're using mostly: > > 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 > >This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks), >we've been keeping up with stable because supposedly all these new >fixes to threading will help us out here. > >We're trying to get FreeBSD to perform reasonably well, in comparison >to Linux, or even what we should expect to see. We're getting about >half the performance we get from gentoo on the same application >(mysql). > >The discussion on the 'freebsd-threads' mailing list about a year ago >seems to match our experiences nowadays pretty well: > > http://lists.freebsd.org/pipermail/freebsd-threads/2004-May/002002.html > >Nothing much seems to have changed, although lots of people claim that >FreeBSD 5.x is now fine, it doesn't seem to be. > >Here's a rough breakdown of the sort of performance we're seeing, this >is the default select-key super-smack but setup for innodb rather than >myisam. > > > >>Using the simple 'select-key.smack' Super-Smack benchmark (50 clients >>with 1000 runs each): >> >>OS CPUs Build Threading Kqueries/sec >>------------------------------------------------------------- >>FreeBSD 1 Pro KSE 10.6 >>FreeBSD 1 Pro libthr 10.6 >>FreeBSD 2 Pro libthr 14.4 >>FreeBSD 2 Source libthr 14.5 >>FreeBSD 2 Source KSE/P (static) 15.7 >>FreeBSD 2 Source KSE/P (dynamic) 15.8 >>FreeBSD 2 Source KSE/S (dynamic) 15.8 >>FreeBSD 2 Pro KSE 15.9 >>FreeBSD 2 Source LinuxThreads 17.7 >>Gentoo 2 Source NPTL 34.0 !! >> >>(KSE/P = KSE with Process Scope Threading, KSE/S = KSE with System >>Scope Threading) >> >> >Quick ideas: Have you tried a kernel with PREEMPTION enabled? I haven't quantified the effect, but it's improved performance in some situations. Have you tried increasing vfs.read_max? Guy -- Guy Helmer, Ph.D., Principal System Architect, Palisade Systems, Inc. ghelmer@palisadesys.com http://www.palisadesys.com/~ghelmer
On Friday, 10 June 2005 at 18:05:37 +0100, Steve Roome wrote:> We're using mostly: > > 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 > > This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks), > we've been keeping up with stable because supposedly all these new > fixes to threading will help us out here.What's the current malloc config for 5.4? Last time I saw this kind of comparison, it proved to be due to malloc debugging. That was on -CURRENT, though. See http://www.lemis.com/grog/diary-dec2004.html#14 for more details. Greg -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050611/5c777a68/attachment.bin
Steve Roome wrote: > We're using mostly: > > 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 > > This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks), > we've been keeping up with stable because supposedly all these new > fixes to threading will help us out here. > > We're trying to get FreeBSD to perform reasonably well, in comparison > to Linux, or even what we should expect to see. We're getting about > half the performance we get from gentoo on the same application > (mysql). > [snip] > Thanks in advance for anyone that has a clue on this, and has anyone > figured out why FreeBSD is just so amazingly slow compared to Linux. > Have you looked around for different compilers and/or different compiler options? I was just remembering how different code can be, depending on which gcc, for example, was used, and definitely which optimization. (i.e. Try "gcc -v" on both systems to see if they match; next see if all compiler options match when they are compiling like -march=pentiumpro.) Meanwhile, I have heard good things about compiler "fill in the blank" for whatever. Not too long ago, I remember hearing about people who preferred to use, say, an Intel compiler for certain things. It might be interesting to see if FreeBSD 4.11 is just as slow as 5.x. And try feeding the right compiler flags using /etc/make.conf or its equivalent. You should also think about whether the file systems are mounted using similar, or equally-performing systems. Rumour has it that Linux file systems performance is .... [flame bait mysteriously deleted]... Your benchmark may produce some interesting results, for example, depending on whether it thrashes a disk, or mainly hits memory. Do they perform the same on small sized (cached) lookups and then FreeBSD bogs down on disk throughput, for example? Last, but not least, I have heard some not-so-impressive things about MySQL 4.1 when compared to 4.0. Perhaps the things I heard were in reality specific to FreeBSD, and so by dropping back to 4.0 on a test server, you might see an unexpected performance boost? (Be sure and delete the tables between runs.) 4.0 is still in the ports tree, and I have heard of some who wished they never upgraded to 4.1. But going backwards is not pretty for a live database, so test both versions now. Billy
On Fri, 10 Jun 2005, Steve Roome wrote:> We're using mostly: > > 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005In my experience, the following factors make a big performance difference: - Thread package. In 5.x, you get process scope threads by default, but it turns out MySQL is tuned for system scope threads, and this is particularly visible in the supersmack benchmark, which competes many client processes against a few server threads. I'm not sure what the condition is of libthr on 5.x, but you could give it a spin. In 6.x, libthr has been largely rewritten and is a great deal faster. I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. - Locking model. Make sure that debug.mpsafenet is set to 1 (i.e., there aren't components in the kernel that force Giant over the network stack. Chances are there are none, but it's worth checking). - Twiddling hyper-threading, which helps or hurts differently in various configurations. - On a UP system, consider compiling a kernel without "options SMP" to reduce locking overhead. I've found the single largest remaining factor to be threading package -- over the past year or so I've about doubled MySQL performance on 5.x leading up to 5.3, largely through SMP locking work, but the remainder of the difference appears to be in the threading package. Robert N M Watson
> I've been working with Steve on this project. We've been playing with various tuning factors, including kernel changes, different stripe sizes on the RAID, "my.cnf" tuning, libmap.conf, and although we can gain a bit here and there, we can't account for the doubling of performance with Gentoo. Anyway, I've included the dmesg and kernel config.And /etc/make.conf ?> The Gentoo install was pretty vanilla-flavoured, as neither Steve or I had installed Gentoo before, and both of us are pretty rusty on any form of Linux.IIRC Gentoo on install detects the processor type and sets for gcc the -march option. FreeBSD does not. Also Gentoo defaults to -O3 (or -O2? I don't have it anymore to check...), so better to par in that also. Since Gentoo compiles practically everything in place, these parameters might affect the results quite much. At least I would check this ;-) BTW, if you will make world and kernel with -march set, you probably better patch it, or you might get a broken loader (sorry for cut&paste, tabs might be broken): $ cat progs/loader.patch --- /usr/src/lib/libstand/Makefile.orig Fri Jun 10 14:03:07 2005 +++ /usr/src/lib/libstand/Makefile Fri Jun 10 14:03:45 2005 @@ -20,6 +20,7 @@ .endif .if ${MACHINE_ARCH} == "i386" CFLAGS+= -mpreferred-stack-boundary=2 +CFLAGS+= -mno-sse2 .endif .if ${MACHINE_ARCH} == "powerpc" CFLAGS+= -msoft-float -D_STANDALONE --- /usr/src/sys/boot/ficl/Makefile.orig Fri Jun 10 14:04:05 2005 +++ /usr/src/sys/boot/ficl/Makefile Fri Jun 10 14:04:29 2005 @@ -12,6 +12,7 @@ .endif .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" CFLAGS+= -mpreferred-stack-boundary=2 +CFLAGS+= -mno-sse2 .endif .if ${MACHINE_ARCH} == "powerpc" CFLAGS+= -msoft-float Similar (with more -mno-smthng) patches are applied by obrien to HEAD, but not to STABLE yet AFAIK, for more see recent discussions in freebsd-current, subj: Newest loader...> Incidentally, this does not seem to be I/O-bound. The data is big enough to stay in the table cache anyway. >I just noticed these particular tests were done on FreeBSD without HTT, whereas the Gentoo test was. However, I can tell you that in earlier runs, the difference between HTT and non-HTT on FreeBSD for this benchmark was negligible. >Regards, > Tom >--- [snip] --- >Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.4-STABLE #0: Thu Jun 9 09:13:03 BST 2005 > root@lithium.lonres.com:/usr/src/sys/i386/compile/PE2850_i386_4 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > real memory = 3489398784 (3327 MB) > avail memory = 3418517504 (3260 MB)-- V.Chukharev
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 :).
I've posted a longer reply, with a trimmed cc list on the -performance
mailing list if anyone is still interested and I'll leave it off
-stable as it's probably become somewhat off topic now.
Sadly, I don't think simply having an async FS is going to solve our
problem though. :(
Ta,
Steve Roome
For refernce:
On Fri, Jun 17, 2005 at 09:28:54AM -0400, David Sze
wrote:> At 05:15 PM 16/06/2005 +0100, Steve Roome wrote this to All:
> 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):
...
Hello, i follows up these thread and i think you all digging on the false possible error location...... I have made many performance tests with RELENG_4 related to RELENG_5 and DragonFly and Gentoo. My results was that RELENG_5 is half as RELENG_4 fast by disk-access (ata-related). I have seen that RELENG_5 with GENERIC Kernel and only modified option HZ=2000. the spread begind with Gentoo (mentoided from me as the slowest, but errare humanum est) Gentoo : 100% time consumption RELENG_4: 67% time consumtion DrangonFly Rel1.2 69-72% time consumption (i think preemtion) RELENG_5 134% time consumtion these tests are made on physically the same Hardware (real, not equal system, same system, same disk, same RAM) with the command: # cd /; /usr/bin/time dd if=/dev/zero bs=1024 count=1024k of=zerofile; rm zerofile the tests are made more then 3 times/period/system. I have made the tests to the beginning of stable-5, and by the release 5.4. after the Release from DragonFly. By the first time i have made a mailing on stable, and i become the answer thath these issues become fixed on RELENG_6..... so i think you have to wait on the developers.... :-(( best regards Michael
On Fri, 17 Jun 2005, David Sze wrote:> 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 ???).The libthr in 5.x is basically an early prototype compared to the more mature work on 6.x, so this result is not all that surprising. David Xu has put a very large amount of work into the libthr on 6.x with some very good results.> 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):This is actually an interesting observation -- on 6.x using P4 Xeon hardware, I've seen a substantial performance improvement from running with libthr with MySQL. Sometimes as much as 30% - 50%. However, amd64 is quite a different beast. BTW, could you run 'file' on the Linux and FreeBSD MySQL binaries and confirm that they're both either 32-bit i386 binaries, or 64-bit amd64 binaries?> 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 > :).I was interested to observe, in some benchmarking a few months ago, that 4.0 MySQL performance on FreeBSD 6.x is a *lot* faster than 4.1 MySQL performance. I don't track MySQL feature development, but I couldn't help but wonder if either there had been substantial reliability changes that impacted file system semantics (which might be indicated by sync/async issues), or whether there had been a lot of performance optimization work for Linux that had swung its use of IPC/etc primitives towards ones that work better on Linux than FreeBSD? BTW, could you confirm that on 6.x, you're setting /etc/malloc.conf so that it's not scrubbing memory on free()? In particular: ln -s jz /etc/malloc.conf as root. Most 6.x debugging features are set as part of the kernel configuration, and your performance results suggest that you've caught them all already, I think, but this one is user space. Also, make sure you are compiling without INVARIANT_SUPPORT -- for packet send tests, I find that even without INVARIANTS, I see a 4% hit for having INVARIANT_SUPPORT in the kernel. Robert N M Watson
On Mon Jul 20, (I was reading the web archive) Mark Kirkwood wrote:> With respect to Mysql performance, I would suspect threading or > threading/kernel interaction as the culprit. (That reminds me, I > don't recall seeing the original poster re-doing the tests with > 6.0-CURRENT - that would be interesting).Sorry for not getting back sooner. I posted these results and anything else that went with this thread to the freebsd-performance mailing list. -current proved a slightly better performer for us, but not enough to bring it even close to the performance we get with gentoo. Off the top of my head the select key benchmarks were ROUGHLY: FreeBSD 5.various + MySQL 4.various : ROUGHLY 16k queries/second FreeBSD 6.0-current + MySQL 4.1.12 : ROUGHLY 18k queries/second Gentoo-something + MySQL 4.1.something : ROUGHLY 30k queries/second. The exact figures were posted to performance- (6.0 tests) and stable- (gentoo vs. freebsd 5.x). Good luck to anyone who can manage to get MySQL to perform as well on FreeBSD as Linux, we've been right out of luck so far and that's really not advocating FreeBSD very well, which is what I'd rather be doing. Steve