Microsoft SQL Server 2008 R2 : Physical server design - CPU architecture

Despite the processing power and flexibility provided by such servers, it's still important to understand the various CPU attributes and configuration options, particularly the choice between 32- and 64-bit processing environments.

In this section we'll address the various aspects of CPU platforms for SQL Server, including multicore systems, CPU cache, clock speed, and the advantages of a 64-bit processing platform.

1. Hyperthreading and multicore

In recent years, there's been a clear shift toward CPUs with multiple cores per die. Dual-core and quad-core chips are now common, and this trend should continue, with 8+-core CPUs not too far away.

Intel introduced its CPU hyperthreading technology in 2003. For each physical CPU, hyperthreading exposes a second virtual CPU to the operating system and is therefore able to provide support for multithreaded applications. SQL Server performance with hyperthreading enabled is often unpredictable, with mixed reports of performance increases, decreases, or no change at all. In contrast, today's multicore systems deliver two (or more) real CPU cores per die, and performance improvements are consistent.

The ability to pack multiple cores onto a single CPU die delivers two significant advantages: the processing capacity of servers is greatly increased, and perhaps more importantly, the overall server cost is reduced. Today's quad-core chips deliver similar performance to four single-core chips. In the single-core era, supporting eight CPUs required an expensive eight-way server. With today's quad-core chips, a much cheaper two-way server can be used that delivers similar processing performance.

Servers suitable for SQL Server deployments are typically ones with support for 2 or 4 dual- or quad-core chips. This delivers between 4 and 16 CPU cores in a relatively cheap two- or four-way server. Such CPU power is usually enough for most database server requirements, with the exception of compute-constrained or very high throughput SQL Server applications.

2. CPU cache and clock speed

With the advent of multicore technology, clock speed has become less important in determining overall CPU performance, with far more weight assigned to the number of cores and the amount of accessible cache.

CPU cache is implemented to speed up access to main system memory. Storing copies of the most frequently accessed memory, cache is typically implemented in three levels. As shown in figure 1, modern CPUs like those belonging to the Intel Core i7 family provide three levels of cache, two of which are private to each core, and one shared area.

The larger the cache, the better; however, much like a disk drive, larger caches have longer access latency. Multiple cache levels are implemented to reconcile between the size and latency goals; level 1 cache is checked before level 2, which in turn is checked before level 3. Finally, the main system memory is accessed if necessary. Such an arrangement results in the fastest overall memory access.

Figure 1. Intel CPUs based on the Nehalem architecture will support between two and eight cores, with each core having 64K of level 1 cache, 256K of level 2 cache, and 8MB of shared level 3 cache.
 

3. CPU platforms

The year 2001 saw the introduction of the first 64-bit CPU for the Microsoft Windows platform. The Intel Itanium CPU was designed from the ground up as a completely new architecture compared to the 32-bit x86 architecture that preceded it. Joint designers HP and Intel intended it for use in enterprise-class servers needing to expand beyond the constraints of the 32-bit platform, particularly in regard to addressable memory.

The original Itanium processor achieved only moderate success, primarily due to its incompatibility with all existing 32-bit software. In response to this, the x64 processors emerged, offering 64-bit processing capability, yet retaining backward compatibility with existing 32-bit software.

Led by AMD with its Opteron CPUs, x64 platforms became popular in large SQL Server deployments. Using the x64 versions of Microsoft Windows and SQL Server, these systems immediately benefited from the advantages of 64-bit computing, while avoiding the problems with 32-bit platforms.

Problems with 32-bit platforms

The primary constraint with 32-bit platforms is addressable memory. Without using the AWE option (discussed shortly), 32-bit systems are limited to 4GB addressable memory, 2GB of which is used by the operating system, which leaves only 2GB for user applications like SQL Server.

The AWE option allows applications to acquire physical memory above 4GB as nonpaged memory dynamically mapped in the 32-bit address space. Using this technique, SQL Server 2008 is able to address up to 64GB of memory.

Although the AWE option allows additional memory to be addressed by SQL Server, it's not without its problems. Overhead is involved in mapping memory in this manner, and the memory can only be used for SQL Server data buffers. Plan cache, sort space, and various other SQL Server resources are unable to use such memory. In contrast, 64-bit SQL Server has no such limitations, offering many advantages:

• Large and directly addressable memory space—Up to 2TB addressable memory can be used by all SQL Server resources, including data cache, plan cache, sort space, indexing, joins, and so forth.

• Enhanced parallelism—64-bit SQL Server supports up to 64 CPUs with enhanced parallelism for much more reliable and linear scalability compared to 32-bit systems.

• Larger cache and improved bus architecture—64-bit CPUs typically offer larger on-die cache and better internal architecture, allowing enhanced data movement between cache and processors.

Organizations that make the decision to move from 32- to 64-bit processing platforms are then faced with a further choice: which 64-bit platform?

Which 64-bit platform?

Itanium CPUs are best used in delivering supercomputer-like performance in systems requiring the full benefits and scale of the 64-bit platform. An HP Integrity Superdome used in a TPC-C test^[] in November 2005 was configured with 1TB (1024GB) of memory and 64 Itanium2 CPUs running at 1.6GHz. Itanium-based systems such as these have exceptionally large memory and I/O bandwidths far exceeding the capacity of x64-based systems.

^[] http://www.tpc.org/results/individual_results/HP/hp_orca1tb_win64_ex.pdf

The vast bulk of 64-bit deployments in use today are based on Xeon or Opteron x64 CPUs. With the exception of all but the largest systems, the x64 platform represents the best choice from both a cost and a performance perspective.

Table 2 shows the number of CPUs supported by SQL Server 2008 running on Windows Server 2008.

With SQL Server's ability to support increasingly larger databases comes a need for larger amounts of RAM, an issue we'll focus on next.