Dual CPU Database Server Comparison

The scope of this test

Our primary objective for this project is quite extensive, so we have narrowed our scope a little more for this article.

Firstly, we focused on single and dual processing systems.

Secondly, we focused on "read" performance. This means that our benchmarks do not try to write information in the tables, but rather, always fetch and report information from one or more tables.

There are two reasons for this:

1. We narrow our focus to a certain kind of application based on when write performance plays a minor part compared to read performance.
2. We want to focus on operation, which involves little harddisk activity, and focus on the platform: the processor(s) and the interaction with the memory.

The benchmarks were inspired by the fact that in many cases, people simply search and browse for information on a website, intranet or another RDBMS application.

So, this article is not about a typical large central database of banks that need to handle a large number of transactions, with frequent writes operations. It is more about a server that needs to handle a lot of ad-hoc queries. AnandTech readers who are searching for a certain article, who like to read the news of the day, or who are checking out the Realtime pricing guide are perfect examples of ad-hoc queries.

Other examples of typical "read heavy" applications are data warehousing applications. The write heavy databases in a company send data to a data warehouse during the night to produce statistical data, which in turn is a read-heavy process.

In these cases, a Systems Administrator or database administrator will try to cache as much information as possible in the fast RAM memory. Database applications and SQL Queries tend to be optimised to be "RAM cache friendly".

Considering that even the best harddisk RAID system accesses information in Milliseconds while RAM memory does the same job in Nanoseconds (Nano is one millionth of Milli), making good use of caching and avoiding storage I/O offers superb performance boosts. As a result, storage I/O limited databases are, in many cases, high end database applications that are run on much more expensive machines than the ones which we are discussing in this article.

Lastly, we test on SUSE SLES 8 (SUSE Enterprise Edition) SP3, Linux kernel 2.4.21. Rest assured that a new report with kernel 2.6 will follow. However, we think that the results might still interest a lot of people as the enterprise market does not upgrade as quickly as desktop users. We found SUSE SLES 8 SP3 Kernel 2.4.21 to be a very stable environment for our database tests.

As a final comment before we move to the benchmarks, I have been working with Anand and his great team for a couple of weeks, and together with your feedback, we will make sure that this project improves over time.