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
AnandTech Forums Database 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).
Despite the fact that we're dealing with a pretty hefty database, the Xeon does not benefit from a massive 4MB L3 cache here. For most transactional database applications, the search queries that will be running are small enough to fit inside caches much smaller than 4MB since they are very specific queries to well indexed databases. More general queries however would increase the need for a larger cache.
What we do see is that the Potomac's 533MHz FSB and higher clock speed come in handy and bring the Xeon to within striking distance of the Opteron, but at 2.2GHz the Opteron holds onto a 5% lead.
Once we look at 4-way configurations, the Opteron maintains an 11% performance lead over the fastest Xeon MP.
When looking at write performance, the Opteron once again maintains a small lead in the 2-way performance category.
...but add another 2 processors to all of the systems and the Opteron flexes its muscle once again. It's clear that AMD put together a very scalable design with Opteron and it's paying off.
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.