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
JohanAnandtech - Friday, September 2, 2005 - link
Sorry couldn't resist :-). (for the rest of the world, pannekoek is dutch for Pancake)Desktop performance is ok, as desktop apps are similar to the workstation apps we tested in the first article. Those apps spend from 5-20% in the OS, while server apps spend up to 80% of their time in the OS!
However, I should point out that we tested Mac OS X SERVER, so it is a problem for the Xserves.
Pannenkoek - Friday, September 2, 2005 - link
I stand corrected then. However, my reasoning still applies, it's just that Apple relies even more on its brand than on technology to sell server systems apparently. Who runs Mac OS servers anyway, it's an oxymoron. ;-)P.S. Do not mock my nick, it served well in beating godlike UT bots, and should be honoured as much as Loque.
Tanclearas - Thursday, September 1, 2005 - link
"Apple told us that the problem lies in the Apachebench (the client side), which stalls from time to time and thus, generates too low of a load on the (Apache) server."How does this explanation make any sense? Linux obviously doesn't have a problem with these "stalls".
JohanAnandtech - Friday, September 2, 2005 - link
What follows is not what Apple said, but my interpretation...They are probably pointing out that the version for Mac OS X has a Mac OS X specific bug. Of course, who is to blame? I am sceptical like you.
mariush - Thursday, September 1, 2005 - link
Page 4 :We used the following on the Opteron based PCs:
Gcc -O2 -mcpu=G5 flops.c -o flops
And, on the G5 machines, we used:
Gcc -O2 -march=k8 flops.c -o flops
I think it's the other way around.
Houdani - Thursday, September 1, 2005 - link
Aye, was gonna point that out also.In addition, on page 3 should you list the Yellow Dog Linux along with OSX in the Software section for the Apple PowerMac G5?
Shinei - Thursday, September 1, 2005 - link
My question is, would the memory latencies be so high for the 970FX if high-end RAM was used for the Linux tests (like, say, some TCCD or BH-5 at 2-2-2-5), instead of the standard 3-3-3-8 SPD that ships with the G5 system? Or is there some limitation to the G5 motherboard that prevents posting with performance RAM as a way for Apple to ensure that only certain, accepted DIMMs are used with their computers?Anyway, these results are very telling about what the OSX86 Macs are going to perform like--that is to say, ~25% slower than the equivalent Windows/Linux boxes running the same hardware...
IntelUser2000 - Sunday, September 4, 2005 - link
That doesn't matter since they are testing workstations, Irwindale and Opteron is also using CAS3 RAM. No workstations/servers use 2-2-2-5 RAM.
The poor scores of OS X compared to Linux makes sense. G5 was rumored to be fast in speccpu benchmarks but came out to be slower. Must be that rumor systems were benched with Linux and the production was benched with OSX.
I am impressed with OS X's features though.
Jedi2155 - Thursday, September 1, 2005 - link
The G5 motherboard has the limitations due to Apple's way to insure you only buy certified ram. The SPD settings must be perfect.ceefka - Thursday, September 1, 2005 - link
I am humbled by the sheer expertise of Johan. Amazing work, Johan!This makes me even more curious about Intel's contribution to the next generation of Macs. How will they compare to the best G5s?