Exchange Server Configuration and Performance
[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at http://go.microsoft.com/fwlink/?linkid=34707.]
Topic Last Modified: 2006-09-06
The Microsoft® Exchange Server Analyzer Tool has determined that your Exchange server is not configured for optimal performance.
During regular operation, Exchange servers access various files. The location of the files may contribute to a performance bottleneck. Groups of interdependent files, such as transaction log drives, are also called resources.
If the distribution of these resources contributes to a disk bottleneck, the Exchange Server Analyzer may display a warning or error about the location of the resources on the Exchange server. To make sure that specific resources are isolated from other load demands, put the resources on a dedicated storage device. The following list describes of how each resource is used, including recommendations for how you can configure the resource.
**Transaction log drives **The transaction log files maintain the state and integrity of your .edb and .stm files. This means that the log files, in effect, represent the data. There is a transaction log file set for each storage group. Because transaction logs are a critical backup component for the data in the Exchange server database files, the Exchange server must commit all data to the log file before it can finish many of its transactions on data. Any delays in writing to the transaction log drive can severely affect the server's performance. Therefore, it is important that you isolate the transaction log drives so that the drives have their own disk subsystem that is not shared by any other server, application, or resource. For best performance, make sure that each transaction log has a dedicated drive.
**Location of the TEMP drive **When first installed, the operating system sets the temporary file location on the same drive that is used by the operating system. This means that any I/O for the TEMP drive competes with I/O for programs and page file operations that are run from that drive. This competition for I/O affects performance. The TEMP drive is used for mail delivery and for the content conversion of large messages. If the TEMP drive becomes bottlenecked, it will affect mail flow and some client applications. To avoid having the operating system compete for I/O with the TEMP drive, and to reduce the risk of performance issues on the Exchange server, it is recommended that you:
Change the global environment setting of TEMP to point to another disk.
Move the TEMP drive to its own disk.
Location of the .edb and .stm files An Exchange database consists of two files:
**An .edb file (MAPI content) **This file stores all MAPI messages and tables that are used by the Store.exe process to locate all messages and checksums of both the .edb and .stm files and MAPI messages.
**An .stm file (non-MAPI content) **This file contains messages that are transmitted with their native Internet content.
Because access to either type of these files is generally random, both file types can be included on the same disk volume. However, it is important not to put .edb and .stm files on the same drive as the transaction logs. Also, because it is important to avoid a performance bottleneck on the drives that contain database files, it is recommended that you put these files on dedicated drives according to each storage group.
**Location of the SMTP Directory **The SMTP queue stores SMTP messages until Exchange writes them to a database (the mailbox store or the public folder store) or sends the messages to another server or connector. Generally, SMTP queues experience random, small I/Os. The Exchange Server Analyzer displays a warning if the SMTP directory is on a drive that is shared by any of the following:
Any other Exchange data file
The TEMP or TMP directories
The page file
The system drive
If there is no disk bottleneck to the SMTP directory, you can safely ignore this warning. However, if the traffic to this drive is high, and the drive exhibits a performance bottleneck, consider moving the SMTP directory to its own drive or increase the capacity of the drive that hosts the SMTP directory.
**Location of the page file **The page file serves as an extension of the physical memory. Specifically, the page file is where the system stores unused pages or pages that the system will need later. The page file is always used, even by servers that have an adequate amount of free memory. This constant use is because the operating system tries to store only necessary pages and sufficient free space for operations. For example, a printing tool that is used only at startup may have some of its memory paged to disk and never brought back if it is never used.
In servers where the physical memory is being used heavily, make sure that all access to the page file is as fast as possible. It is recommended that you create a second page file on a drive that is dedicated to the page file.
For More Information
For more information about Exchange Server performance, see the Exchange Server 2003 Performance and Scalability Guide (http://go.microsoft.com/fwlink/?LinkId=47576).
For more information about troubleshooting Exchange Server performance issues, see Troubleshooting Microsoft Exchange Server 2003 Performance (http://go.microsoft.com/fwlink/?LinkId=47588).
For more information about best practices for designing storage architectures, see Best Practices Common to Multiple Architectures (http://go.microsoft.com/fwlink/?LinkId=72988).
For more information about disk sizing, latency, and I/O rates, see How to Calculate Your Disk I/O Requirements (http://go.microsoft.com/fwlink/?linkid=69747).