Intel Woodcrest, AMD's Opteron and Sun's UltraSparc T1: Server CPU Shoot-out

MySQL Results: Scaling

Back to our main subject, our astute readers have probably already noticed a weird anomaly. Let us analyze this further. If you look closely at both our measurements, Quad-core and Dual-core x86, you'll notice that the scaling is negative. To make it more clear, we made an average of all concurrency numbers from 5 and higher.

MySQL Linux (Queries/s)
	Sun T1 4/8 cores 1 GHz	MSI K2-102A2M Opteron 275	Xeon 5160 Woodcrest 3 GHz	MSI K2-102A2M Opteron 280
Average Dual-core (T1: quad-core)	362	749	996	805
Average Quad-core (T1: octal-core)	433	590	904	622
Speedup Dual to Quad	20%	-21%	-9%	-23%

This is nothing short of amazing. It seems like an anomaly, but this is not the case. These benchmarks have been checked, verified and checked again. They are accurate. The x86 cores running on Linux perform better with two cores than with four cores, but the T1 running Solaris actually improves performance going from 4 to 8 cores.

So who is guilty? Linux or the Opteron system? We had to test with Solaris on the Opteron to be sure. However, the Serverworks chipset of our MSI 1U server was not supported by x86 Solaris. So we went back to our homebuilt server, based on the MSI K8N Master2-FAR.

MySQL Solaris (Queries/s)
	Sun T1 4/8 cores 1 GHz	Opteron 280 Solaris	Opteron 280 Linux
Average Dual-core (T1: quad-core)	362	456	799
Average Quad-core (T1: octal-core)	433	605	625
Speedup Dual to Quad	20%	33%	-22%

And this puts the performance of our UltraSparc T1 in a whole different perspective. First of all, it is clear that while MySQL might not be the most scalable database, the current kernel of Linux is not helping matters. We did tweak the Linux kernel two ways: the 2.6.15 kernel was optimized for either Intel's or AMD's architecture and the AMD architecture also got NUMA support.

So what is going on here? After talking to our MySQL guru (P. Zaitsev), it turns out that in some circumstances, MySQL might cause trouble for the Linux mutex (mutual exclusion) implementation: "mutex ping-pong". The mutex implementation makes sure that two threads cannot access data in the main memory that is locked by another thread.

It seems however more a MySQL problem than a Linux one, as other databases like DB2 scale very well in Linux. For DB2 under the same load we noticed a performance increase of no less than 80-85% when going from two to four cores. Also, with some loads, the bad scaling kicks in later than our "Select dominated" load. Intel's performance labs told us that they also ran into the same problem.

These issues are not as severe as the problems we encountered with MySQL in Mac OSX. Note that Apple seems to have recognized the problem and seems to offer a workaround. We'll report back with other MySQL workloads to investigate the MySQL scaling problem further.

PostGreSQL Results

PostgreSQL 8.0.7, another open source database, uses processes and not threads to deal with connections. The consequence is that the benchmark numbers are a lot more stable: once each core is busy with it's process, you almost get maximum performance. In other words, the results didn't change much from 5, 10 or 25 concurrent users. To keep things simple, we only list the numbers with 20 users, which results in peak performance. The queries per second numbers at 5 and 25 were only a few percent lower. We did not include the T2000 Sun Server as the optimal PostGreSQL configuration is still under investigation.

PostgreSQL 8.0.7 (Queries/s)
DL385 1 x Opteron 280	517
Intel 2 x Xeon "Irwindale" 3.6 GHz	448
MSI 1U 1 x Opteron 275	490
MSI 1U 1 x Opteron 280	524
Intel 1 x Xeon 5160 WC 3 GHz	673

Another clear victory for Woodcrest. On the Opteron, every 10% in clockspeed increase seems to result in a 7% performance increase. So if we extrapolate, an Opteron 3 GHz would arrive at 616 queries per second.