Determining RAM and CPU Specifications

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

As hardware continues to improve, hardware vendors frequently change the RAM and CPU configurations in the servers they offer. Use the information about performance improvements and scaling factors in the sections that follow to choose the hardware that best meets your organization’s needs.

When designing RAM and CPU specifications for server clusters, also consider the failover policy that you plan to use and the maximum number of File Share resources and share subdirectories that will be hosted on any one node after a failure. Each node must have the RAM and CPU resources required to host the resources of one or more failed nodes, depending on your failover policy. For more information about failover policies and server cluster capacity planning, see "Designing and Deploying Server Clusters" in this book.

Note

• Many of the figures presented in this section are derived from NetBench statistics for file server throughput. NetBench is a portable Ziff Davis Media benchmark program that measures how well a file server handles file I/O requests from 32-bit Windows clients. NetBench provides an overall I/O throughput score and average response time for servers, along with individual scores for clients. You can use these scores to measure, analyze, and predict how well your server can handle file requests from clients.

Reviewing Windows Server 2003 CPU Specifications

Table 2.11 describes the recommended CPU speed and number of processors supported by Windows Server 2003.

Table 2.11   CPU Requirements for Windows Server 2003

Reviewing Operating System Performance Improvements

Even if you plan to use existing hardware to run Windows Server 2003, you can benefit from performance enhancements available in Windows Server 2003, as well as client and server protocol improvements available when using clients running Windows XP Professional.

Table 2.12 describes performance improvements that can be gained by migrating to new operating systems on identical hardware.

Table 2.12   Operating System Performance Improvements on the Same Hardware

These figures are based on the following assumptions:

• The server is uniprocessor (UP), 2P, 4P, or 8P.

• For each comparison, the server hardware is the same.

• No memory, disk, or network bottlenecks prevent the processor from performing at full capacity.

Reviewing Performance Improvements Gained by Upgrading Processors

Table 2.13 describes performance improvements that can be gained by upgrading server processors. Upgrading processors improves processing power, memory bandwidth, I/O bandwidth, and the system bus. These figures are based on actual processor improvements, not operating system improvements. If you plan to use processors that are faster than those listed here, performance will be greater than the following figures show.

Table 2.13   Performance Improvements Gained by Upgrading Processors

Reviewing Performance Improvements Gained by Adding Processors

To increase performance, consider using more than one processor in your file servers. One advantage of using multiple processors is the ability to handle more concurrent clients, resulting in higher scaling factors at high client loads. Table 2.14 describes the NetBench throughput improvements gained by adding processors on file servers running Windows Server 2003.

Table 2.14   Performance Improvements Gained by Adding Processors

* The scaling factors are based on a range of client loads.

Determining the Client Load Based on Processor Utilization

NetBench stresses the system by applying a heavy load on the file server. Microsoft used the most intensive CPU operations — file opens and file creates (subsequently described as opens/creates) — to translate a NetBench client load to a more realistic client load.

To determine the client load, Microsoft observed approximately 820 opens/creates per second at peak NetBench throughput (100-percent CPU utilization) on a Xeon 900-MHz server with a single processor (UP). Table 2.15 describes active client loads for light, medium, and heavy user loads at 70-percent CPU utilization. The client loads are defined as follows:

• Light: one open/create every 10 seconds

• Medium: two opens/creates every 10 seconds

• Heavy: three opens/creates every 10 seconds

Assuming that a light user load causes one open/create every 10 seconds, a UP Xeon 900-MHz server can handle 5,700 users at 70-percent CPU utilization and 8,200 users at 100-percent CPU utilization. (These figures are derived by dividing the opens/creates per second at peak NetBench throughput by the opens/creates per second for light users.)

The figures in Table 2.15 for the UP Xeon 900-MHz server are based on the following assumptions:

• No memory, disk, or network bottlenecks prevent the processor from performing at 100-percent capacity.

• The clients are running Windows XP.

The figures for 2P, 4P, and 8P Xeon 900-MHz servers were calculated by using the scaling factors described in Table 2.14. For example, on a 4P Xeon 900-MHz server, under a heavy client load of three opens/creates every 10 seconds, the server can handle 3,400 to 4,400 active users. This figure is derived by taking the 1,900 heavy-load users supported on a UP Xeon 900-MHz server and multiplying that figure by the UP-to-4P scaling factors of 1.8X to 2.3X provided in Table 2.14.

Table 2.15   Number of Active Users Supported Based on a NetBench-Type Workload

Determining RAM Specifications

Using adequate RAM in file servers ensures that Windows Server 2003 can temporarily cache (store) files in memory, reducing the need to retrieve files from disk. Table 2.16 describes the minimum recommended RAM and maximum RAM for Windows Server 2003.

Table 2.16   Minimum and Maximum RAM for Windows Server 2003

To determine the amount of RAM required to support the file server workload, review the number of remote file handles that can be efficiently supported by a file server running Windows Server 2003. Next, review how additional RAM affects the total size of files, or file set size, that can be held in memory at any time.

Remote concurrent file handles

A file server running Windows Server 2003 with 1 GB of RAM can efficiently support approximately 100,000 remote concurrent file handles, regardless of the size of the files. If your users are likely to have more than 100,000 files open at a time, plan to split this load across two or more servers.

File set size

On a file server with 1 GB of RAM, Windows Server 2003 can hold approximately 500 MB of file content and NTFS metadata in memory. (The amount of memory used for NTFS metadata depends on the depth of the directory hierarchy and query distribution, among other factors.) Windows Server 2003 uses the rest of the RAM for providing nonpaged pool and other operating system functions. For each additional gigabyte of RAM that you add, Windows Server 2003 can use the entire RAM capacity for storing file content in memory. For example, a file server with 3 GB of RAM can support approximately 2.5 GB of file content in memory. When the file set size exceeds the amount of memory, files are paged to disk. This paging can result in disk bottlenecks, though using a fast disk subsystem can alleviate this problem.

When determining how much RAM you plan to install in file servers, consider the following guidelines:

• When users typically access the same files, the file set is known as "hot," because the files are frequently stored in memory. For hot file sets, invest in more RAM to accommodate the entire hot file set. Typically, hot file sets are less than 1 percent of the file set, although this figure can vary.

• When users access random files, the file set is known as "cold." For cold file sets, invest in faster disks, because users typically open files that are not already in memory, and the response time is limited by disk latency. For example, if you can cut disk latency in half by using a faster disk subsystem (including number of disks, mechanical speed, and disk cache), compare the cost of doing so to the amount of RAM it would take to achieve similar performance. Using a faster disk subsystem might be less expensive.