Bottleneck Search
We did some basic profiling, and this allows us to eliminate a few bottlenecks as the cause of the performance issues. As we discussed in the first article, network performance wasn't an issue: we used a direct Gigabit Ethernet link between client and server. On average, the server received 4 Mbit/s and sent 19 Mbit/s of data, with a peak of 140 Mbit/s. That peak of 140 Mbit/s is only achieved when running at the highest performance (500-600 queries per second); the Apple machine stayed well below that peak.Another theory is published in a personal blog: the fsync() theory. Basically, the command forces the OS to write all the pending data to the disk drive, and then forces the disk drive to write all the data in its write cache to the platters. The theory is that most OSes do not force the last step, while Mac OS X does. However, this theory is not the reason for the lackluster performance that we noticed.
First of all, we saw at most 23 KB/s writes, again at peak performance, in the case of the Dual G5 running Mac OS X at 274 queries per second. To avoid excessive writing, our Dbbench client has a warm-up period where the database is put under load but no measurements take place. This makes our benchmarking consistent, and lowers the pressure on the disk system. You can read more about our MySQL test methods here. Secondly, we were using the MyISAM database engine, which does not support this "transactional safe writing".
MySQL Configuration
We played around with all the configurations' variables mentioned here, but none of them made any real difference for the Mac OS X MySQL performance. Again, the "query cache" was off, as we wanted to test worst case performance. More info on why we test this way can be found here.For those who are curious, we did a quick test with "query cache on". The Apple machine scored about 500 queries per second. In the case of the Linux x86 machines, we had to use several clients. It seems that each client can fire off at most 1000 queries per second. This appears to be a Windows 2003 limitation, since faster Opterons (2.6 GHz instead of 2.4 GHz) or quad Opteron clients (instead of dual) couldn't get us past this limit either. With several clients firing off queries, the Linux machines were capable of a peak of 2700 queries per second (and probably more - we had 3 clients at most), while the Mac was still limited to 500 queries per second. Note that this is "best case" performance, since up to 60% of the queries were picked out of the cache. With more random queries, these numbers are significantly lower.
Let us see if LMBench can make us wiser, now that we can compare Linux and Mac OS X on the Apple PowerMac.
Facebook
Twitter
RSS
47 Comments
View All Comments
stmok - Thursday, September 1, 2005 - link
LOL...As everyday passes, it seems more "interesting things" are revealed from Apple solutions.ViRGE - Thursday, September 1, 2005 - link
Granted, some of this was over my head(more than I'd like to admit to), but your results are none the less very interesting Johan. Now that we have the Linux/G5 numbers, there's no arguing that there's a weakness in MacOSX somewhere, which is a bit depressing as a Mac user, but still a very useful insight as to how there's obviously something very broken in some design aspect of the OS(it simply shouldn't be getting crushed like it is). My only question now is how Apple and its devs will respond to this - it is pretty damning after all.Thanks for finally getting some Linux/G5 numbers out to settle this.
sdf - Friday, September 2, 2005 - link
By changing hardware platforms.No, seriously.
A transition from PowerPC to Intel would be the perfect time to correct ABI flaws like this. It isn't that the G5 causes the slow down, it's that the slow down (maybe) can't really be fixed without breaking binary compatibility. A CPU transition is clearly going to do that anyway, so maybe they'll just wait...
toelovell - Thursday, September 1, 2005 - link
I am kind of curious to see how Darwin would work on an x86 based system for these same tests. There are x86 binaries for Darwin 8. So it should be possible to run these tests and compare Darwin with Linux on an x86 platform. This would help to see if the OS really is the limitation. Just a thought.JohanAnandtech - Thursday, September 1, 2005 - link
If linux is capable of pushing the G5 8 times higer than with Mac OS X, there is little doubt on my mind that the OS is the problem. Or did I understand you wrong?Anyway, I have no experience whatsoever with Darwin. My first impression is that installing Darwin on x86 is probably a very masochistic experience, due to lack of proper drivers. We might get it working but can it really run MySQL and other apps? THere are probably libraries missing... Will the results be representative of anything as it is probably tuned for just getting it running instead of performance? Anyone with Darwin x86 experience?
wjcott - Thursday, September 1, 2005 - link
The only interest I have in a mac OS is if they are going to sell it without a computer. I would love to have OS X, but I must build the machine.Quanticles - Thursday, September 1, 2005 - link
Every component must be fine tuned to the upmost degree... Every BIOS Setting... Every Hidden Register... *crazy eyes* =)