AMD Opteron vs. Intel Xeon: Database Performance Shootout
by Anand Lal Shimpi, Jason Clark & Ross Whitehead on March 2, 2004 2:11 AM EST- Posted in
- IT Computing
Order Entry Stress Test Results
The results are split up into two categories: 2-way and 4-way setups. Remember that the 3.2GHz Potomac based Xeon is only available in 2-way configurations and is thus absent from the 4-way graphs. The labels are as follows: CPU Name Clock Speed/FSB Speed/Cache Size (e.g. Xeon 3.0GHz/400/4MB = Xeon 3.0GHz, 400MHz FSB, 4MB L3 cache). Keep in mind that all Xeons have a 512KB on-die L2 cache, and all Opterons have a 1MB on-die L2 cache (but no L3 cache).
With a heavier workload the performance between the top three performers (Xeon MP, Xeon and Opteron) are virtually identical. Note that the number of reads being reported here is in thousands, we are actually talking about 239 million reads from this database in the test here for the Xeon MP.
What once was a close race is now an Opteron victory, with the Opteron 848 taking up an 8.5% performance lead over the latest and greatest Gallatin 4MB. Once again we see that the Gallatin's Achilles' heel is its 400MHz FSB, double it and then AMD may be in trouble.
We get a similar set of standings when looking at write performance; in 2-way configurations the Opteron and Xeon MP are basically tied.
And once again, moving to 4-way configurations shows that the Opteron is a much better scaler, and much better suited for 4-way servers than the Xeon MP.
Facebook
Twitter
RSS
58 Comments
View All Comments
Rand - Friday, May 20, 2005 - link
perlgreen - Tuesday, June 1, 2004 - link
Is there any chance that you guys could do more tests and benchmarking on Linux for IT Computing/Servers? I really like your site, but it'd be really nice if there would be more stuff for fans of the Penguin!cheers,
Campbell
ragusauce - Friday, March 5, 2004 - link
#54We have been building from source and trying different options / debug versions...
DBBoy - Friday, March 5, 2004 - link
#47 - In OLAP, or poorly indexed environments where the amount of data exceeds the 4 MB L3 cache of the Xeons the Opteron is going to shine even more with it's increased memory bandwidth.Assuming you do not bottleneck on the disk IO the SQL cache/RAM will be utilised much more thus putting more of a burden on the FSB of the Xeons in addition to allowing the Opteron's memory bandwidth to display it's abilities.
Jason Clark - Friday, March 5, 2004 - link
ragusauce, using binaries or building from source?Cheers
ragusauce - Friday, March 5, 2004 - link
We have been doing extensive testing of MySQL64 on Opteron and have had problems with seg faults as well.zarjad - Thursday, March 4, 2004 - link
Great, thanks.My thoughts:
In this type of application you are likely to use more than 4GB memory.
Memory bandwidth should matter because you will be doing a lot of full table scans (as opposed to using indexes).
Jason Clark - Thursday, March 4, 2004 - link
zarjad, I'll get back to you on that question I have some thoughts and amd discussing them with one of the guys that worked with us on the tests (Ross).zarjad - Thursday, March 4, 2004 - link
Jason, any comments on #47?Jason Clark - Wednesday, March 3, 2004 - link
The os used was windows 2003 enterprise which does indeed support NUMA. So NUMA was enabled.. this was covered in an earlier response.