3 Basics of Exchange Server Performance

Microsoft Exchange Server administrator's job is all about getting the mail through, keeping the system running, and giving users the impression that Exchange Server is 100 percent dependable. To achieve these goals, you need to concentrate on several performance fundamentals: hardware, design, and operation. These three basics come into play for all Exchange Server organizations, whether you're running Exchange 2000 Server or Exchange Server 5.5. Reliable and capable hardware is the foundation of Exchange Server performance, but the design into which you place that hardware and the way that you operate the hardware are just as important when you want to achieve maximum performance over a sustained period.

Fundamental No. 1: Hardware
An adequate and balanced hardware configuration provides the platform for good Exchange Server performance. To meet your performance goals, your servers must strike a balance among these three essential components: CPU, memory, and disk.

Server configuration essentially comes down to how many CPUs the server has and how fast they are, how much memory the server has, and what type of disk subsystem the server uses. Given the speed of today's CPUs and the relatively low cost of memory and disks, you'll be hard pressed to underconfigure a server. Even the smallest off-the-shelf server—with, for example, a 700MHz CPU, 256MB of RAM, and three 18GB disks with a RAID 5 controller—can support several hundred Exchange Server mailboxes. (For an explanation of the benchmarks that vendors use in server-sizing guides, see the sidebar "Making Sense of Benchmarks.") High-end servers (i.e., servers that support more than 1000 mailboxes or servers that are designed for high availability) present more of a challenge, mostly because of the different combinations of hardware that you can apply to provide the desired performance level.

CPU statistics. Most Exchange Server machines are equipped with only one CPU, but hardware vendor tests demonstrate that Exchange 2000 scales well using SMP. In Compaq tests, an increase from two processors to four processors led to a 50 percent improvement in capacity; an increase from four processors to eight processors also led to a 50 percent increase. Considering SMP's overhead, this performance is excellent and testifies to the Exchange Server code base's multiprocessing capabilities. (Microsoft says Exchange 2000 Service Pack 1—SP1—will support more than eight processors, but factors other than the CPU will probably limit most configurations, and 8-way machines can currently meet the needs of even the largest corporate Exchange 2000 organization.)

CPUs get faster all the time. (Intel recently announced the availability of a 1.5GHz Pentium IV processor.) Level 2 cache is particularly important for good Exchange Server performance, so use systems with as much Level 2 cache as possible. This special area of the processor caches instructions, and its size depends on the processor's model. Intel's Pentium III processors' typical Level 2 cache size is 256KB, whereas the company's Xeon processors can have Level 2 caches as big as 2MB. Currently, Xeon processors are the best platform for Exchange Server because of their cache size and the nature of the chipset, which Intel has optimized for server applications.

Keep in mind that your goal should be to saturate your machine's processing capability; to do so, you need to remove any bottlenecks. Typically, you should first address any memory deficiencies, then add storage subsystem capacity, then increase network speed (100Mbps should be sufficient for all but the largest Exchange Server systems). If you still need to increase CPU saturation after you've tuned these components, you can add more processors or increase the processors' clock speed.

Memory and cache. To optimize the memory demands that Exchange Server makes on the OS, Exchange 2000 and Exchange Server 5.5 both implement a mechanism called Dynamic Buffer Allocation. DBA monitors the level of activity on a server and adjusts the amount of virtual memory that Exchange Server's database engine (i.e., the Extensible Storage Engine—ESE) uses. Exchange Server implements DBA as part of the Store (Microsoft's generic term for the Information Store—IS), so you'll sometimes see the Store process grow and contract quite dramatically on a server that experiences intermittent periods of heavy demand. You'll also see the Store fluctuate on Exchange Server systems that run other applications—especially database applications such as Microsoft SQL Server—when multiple applications request memory resources.

On servers that run only Exchange Server and therefore experience a consistent level of demand, the Store process tends to grow to a certain level, then remain constant. (Exchange 2000 machines aren't in this group because all Exchange 2000 servers also run Microsoft IIS to support Internet protocol access.) Don't let a large Store process worry you—it simply means that DBA has observed that no other active application wants to utilize memory and so has requested additional memory to cache database pages. The net result is a reduction in the amount of system paging; this reduction aids performance.

To see how much memory the ESE is utilizing, you can use the Database Cache Size (Information Store) counter on the Performance Monitor's Database object. Figure 1 shows a typical value from a small Exchange 2000 server under moderate load. This server has 256MB of RAM but has allocated approximately 114MB of virtual memory to the ESE. Note that the amount of virtual memory that the ESE uses will increase as you load more storage groups (SGs) and databases—one reason why experienced systems administrators stop to think before they partition the Store.

The ESE uses RAM to cache database pages in memory. When a server doesn't have enough physical memory, the ESE caches fewer pages and increases disk access to fetch information from the database. The result is an increased strain on the I/O subsystem, which must handle more operations than usual. You might conclude that you need to upgrade the I/O subsystem, probably installing additional disks and redistributing I/O. However, increasing the amount of RAM available to the server is usually more cost-effective, so always consider this step before any other action.

Maximum disk performance. Exchange Server is essentially a database application, and like all other database applications, it generates a considerable I/O load and stresses both disk and controller components. Any performance-management exercise must therefore include three steps: Properly distribute the source of I/O (i.e., the files involved in messaging activity) across disks, ensure the correct level of protection for essential files, and install the most appropriate hardware to handle disk activity.

The first step is to separate transaction-log sets and database files, even on the smallest system. This procedure ensures a maximum chance of maintaining information after a disk crashes. If you place logs on one spindle and the database on another, the loss of one won't affect the other, and you can use backups to recover the database to a known state. If you place logs and database on the same spindle, however, a disk failure inevitably results in data loss.

The second step is to properly protect the transaction-log sets. The data in the transaction logs represents changes in information between the database's current state (i.e., pages in RAM) and its state at the last backup (i.e., pages on disk). Never place transaction logs on an unprotected disk; use RAID 1 volumes with controller-based write-back cache, which provides adequate protection without reducing performance. Separate transaction-log sets on servers running Exchange 2000 Enterprise Server with multiple SGs. The ideal situation is to assign a separate volume for each log set.

The third step is to give as much protection as possible to the Store databases. Use RAID 5 or RAID 0+1 to protect the disks that hold the mailbox and public stores. RAID 5 is the most popular approach (Microsoft has recommended a RAID 5 approach since it launched Exchange Server 4.0), but RAID 0+1 is becoming more common because it delivers better I/O performance and avoids the necessity of enabling a write-back cache. Compaq has performed tests that demonstrate that one spindle in a RAID 0+1 set can support the I/O that 250 active Exchange Server users generate. Thus, a large server that supports 2500 active users would need a 10-disk RAID 0+1 set. For maximum performance, concentrate on each disk's I/O capacity rather than on how many gigabytes it can store.

After you've equipped your server with sufficient storage, you need to monitor the situation to ensure that the server delivers the desired performance. To get a complete picture, monitor each device that hosts a potential hot file (i.e., a file that generates most of the I/O traffic). For Exchange Server 5.5 machines, these devices include those that hold the Store, the Message Transfer Agent (MTA), and the Internet Mail Service (IMS) work files. For Exchange 2000, take the same approach but also monitor the device that hosts the SMTP mail drop directory, and consider that the Store might be partitioned into multiple databases, each of which you need to monitor.

To quickly assess storage performance for an Exchange Server machine, you can use several Performance Monitor counters that examine disk response times and queue lengths. (For information about Performance Monitor and similar tools, see Cris Banson, "NT Performance Tuning," page 40, or read Curt Aubley, "Windows 2000 Performance Tools," http://www.win2000mag.com, InstantDoc ID 8198.) To monitor response time, you can use any of the following Physical Disk object counters:

• Avg. disk sec/Read
• Avg. disk sec/Write
• Avg. disk sec/Transfer

For acceptable performance, each device should perform random I/O operations in 20 milliseconds (ms) or less. Sequential operations should take place in less than 10ms. You need to take action when devices exceed these thresholds. The easiest course is to move files so that less heavily used devices take more of the load. The alternatives are more drastic: Relocate mailboxes, public folders, or connectors to another server, or install additional disks and separate the hot files.

You should also monitor the Pages Read and Pages Writes performance counters for the Memory object because they indicate the hard page faults that result in a disk access. The sum of these two values shouldn't exceed 80ms (i.e., roughly the I/O limit for one disk drive). If the sum exceeds 80ms, you should add more physical memory to your server and possibly locate the page file on a fast drive (although the latter solution is less efficient than adding memory).

   Previous  [1]  2  Next