Exchange Store and Extensible Storage Engine Tuning

  • Article

 

Exchange Server 2003 can handle up to 25 databases per server. The total storage space is made up of a maximum of four production storage groups with five databases per storage group and a Recovery Storage Group that can handle up to five databases for recovery purposes.

When you use Exchange Server 2003 or a later version of Exchange, it is recommended that you add an additional storage group for each new database until the maximum number of storage groups has been created. It is also recommended that you do this instead of adding multiple databases within a single storage group, as was recommended with Exchange 2000 Server.

This recommendation lets administrators spread the load of mailboxes across as many stores and storage groups as possible. This creates a more easily manageable Exchange storage topology. Such a topology has the following advantages:

  • Databases can be smaller.

  • Drive input/output (IO) can be better managed.

  • Recoverability increases.

For example, consider the following configurations for Exchange storage topology. In these examples, the storage groups are named SG1 through SG4. The databases that are created over time are named DB1 through DB8.

In versions of Exchange that are earlier than Exchange Server 2003, you may have configured your Exchange storage topology as follows:

SG1: DB1, DB2, DB3, DB4

SG2: DB5, DB6, DB7, DB8

In Exchange Server 2003 and in later versions of Exchange, we now recommend that you configure your Exchange storage topology as follows:

SG1: DB1, DB5

SG2: DB2, DB6

SG3: DB3, DB7

SG4: DB4, DB8

For more information about storage groups in Exchange Server 2003, see Microsoft Knowledge Base article 890699, "How to configure storage groups in Exchange Server 2003" (https://go.microsoft.com/fwlink/?LinkId=3052&kbid=890699).

Single Instance Support

Exchange Server 2003 fully supports single instance messaging. If a single message is addressed to multiple recipients and those recipients are located in the same database, only one message is sent to the database. The recipients receive pointers to the single message.

If message recipients are located on multiple databases in a storage group, a single copy of the message is delivered to each database where recipients are present. Additionally, multiple copies of the message are held in the transaction log set for the storage group.

There are many theories about how to make the best use of single instance support. Some people prefer to locate whole departments of users in the same database, therefore potentially saving disk space; others do not like this approach as a database failure can make an entire department become unavailable.

Single instance storage is designed to improve the delivery performance of the server when delivering to many people, and not necessarily to save space on the disk.

Single instance is also retained if you move mailboxes between Exchange databases, storage groups, and servers.

Increasing Page Table Entries on Servers Running Windows 2000 Server

On large scale-up mailbox servers that have the /3GB switch set, the Store.exe process has more virtual address space in user mode and the kernel address space is reduced to 1 GB. Unfortunately, this issue can cause an imbalance if a heavily-loaded server can run out of page table entries. If the issue continues, your server can experience resource failures when writing data to the disk or network connection failures.

For detailed instructions, see How to Increase System Page Table Entries in Windows 2000.

Online Database Maintenance

Each mailbox and public folder store requires periodic online maintenance to be run. By default, each database is set to run online maintenance between 1:00 AM and 5:00 AM. Online maintenance performs a variety of tasks necessary to keep the store in good health, including but are not limited to:

  • Task 1   Checking Active Directory to determine whether there are any deleted mailboxes.

  • Task 2   Permanently removing any messages or mailboxes that are beyond the configured retention period.

  • Task 3   Performing online defragmentation of database files.

These operations have specific performance costs, and you should understand these costs before you implement an online maintenance strategy.

Task 1 performs an Active Directory lookup for each user in the database. The more users you have in each database, the more LDAP directory searches are made. These searches are used to keep the mailbox store synchronized with any Active Directory changes (specifically, look for deleted mailboxes). The performance cost of this task is negligible on the Exchange server, but it can be significant on Active Directory servers depending on the number of users, the number of databases, and the online maintenance times of each database. In a corporate scenario, the online maintenance typically occurs at night, when very few users are logged on and the load on Active Directory servers is very low. The extra domain controller load created by online maintenance should not be a problem in this scenario.

If Exchange Server 2003 is installed in a global data center and serves customers from multiple time zones, the default online maintenance time may become an issue. The effect online maintenance has on Active Directory is proportional to the number of users in each of the server's databases. A check for a deleted mailbox is performed against each user in each database. Therefore, if you have 10,000 users spread over multiple databases on a server, 10,000 LDAP searches against Active Directory will occur at the default start time of 1:00 AM. If Active Directory servers are always (around the clock) under moderate load, stagger the online maintenance (set each database to start maintenance at a different time). Staggering the online maintenance is especially critical if you have hundreds of thousands of users spread across dozens of servers and hundreds of databases.

Tasks 2 and 3are very disk intensive and only affect the server where the maintenance is being run. During this part of online maintenance, the server may be perceived by users as sluggish if many databases are set to perform online maintenance at the same time. Again, in corporate scenarios, this maintenance would occur at night when the server can easily handle the extra load. In a global data center, it may make sense to stagger the database schedule (in respect to each other on a single server) to spread disk-intensive tasks over a greater period of time.

Online backup requires additional consideration. Backing up an Exchange Server 2003 database stops the maintenance of any database in that storage group (maintenance restarts if the backup finishes before the maintenance interval has passed). If you have two databases in a single storage group and one is running online maintenance, if a backup is started against either database, the online defragmentation on the database (which is running online maintenance) is stopped. It is critical that the backup time for any database in a storage group not conflict with the maintenance times of any database in the same storage group. If it does, backup stops the online defragmenting part of the online maintenance and the database may never finish defragmenting.

The correct online maintenance strategy can be devised by examining the user profile (such as times of low activity); knowing how many users, databases, and servers are in the site; and coordinating this information with the online backup strategy.

Here is an example of an online store maintenance schedule for a corporate Exchange 2003 mailbox server, which hosts users for a single time zone:

First Storage Group

Database One: Online maintenance runs between 21:00 and 01:00.

Database Two: Online maintenance runs between 21:30 and 01:30.

Database Three: Online maintenance runs between 22:00 and 02:00.

Online backup begins at 02:00 and backs up all databases in the first storage group when all databases have finished online maintenance.

Second Storage Group

Database Four: Online maintenance runs between 22:30 and 02:30.

Database Five: Online maintenance runs between 23:00 and 03:00.

Database Six: Online maintenance runs between 23:30 and 03:30.

Online backup begins at 03:30 and backs up all databases in the second storage group when all databases have finished online maintenance.

This configuration staggers the Active Directory LDAP queries generated by online maintenance, which are performed in the first minutes of the procedure, and makes sure that online backup does not interfere with online defragmentation.

The third task of defragmenting the database is made up of 18 separate subtasks. After a subtask has started, it must complete. Therefore, if subtask 12 is still running at the end of the online maintenance window, this task completes fully before the process exits. Therefore, online maintenance can run over the time window. Subtask 13 runs during the next online maintenance window. Depending on the run window and backup schedule, it may take more than one day for a full defragmentation to finish.

Message Promotion on Move Mailbox

Although Internet protocol clients such as IMAP4 and POP3 use the streaming store (.stm file) for reading and writing data, you should understand that the move mailbox function in Active Directory Users and Computers moves data into the .edb file. Therefore, clients who use POP3 and IMAP4 to access their mailboxes may see decreased performance after their mailbox has been moved between databases or servers. When logging on, message size is calculated and a MAPI to MIME conversion occurs in the memory and on the disk of the server. In extreme cases this can cause very large temporary files being created on the Exchange 2003 server.

If you move hundreds or thousands of mailboxes, you can mitigate potential issues by using the following recommendations. On the destination server, do both of the following:

  • Make sure that the TMP/TEMP environment variables point to a very fast RAID0+1 spindle set (up to 12 disks for large mailbox servers). For stand-alone mailbox servers, the system environment TMP/TEMP variables should be adjusted. For clustered servers, the variables should be configured for the service account that the Cluster service is running under. For detailed instructions, see How to Move the TEMP and TMP Directories.

  • Set the Compatibility registry value for the Internet client protocols in use to inform the store that it should use approximate instead of exact calculations for message sizes. For detailed instructions about how to set the Compatibility registry value for POP3 clients, see How to Set the Compatibility Registry Value for POP3 Users. For detailed instructions about how to set the Compatibility registry value for IMAP4 clients, see Fast Message Retrieval for IMAP4 Users.

Virtual Address Space and Store Database Cache Size

The Store.exe process in Exchange Server 2003 has a finite amount of memory that it can address. This amount is known as the virtual address space. For larger servers, you may want to manually adjust the virtual address space for optimal memory usage.

The Store Database Cache, also known as the ESE buffer, provides a large caching area for database transactions before they are committed to the store. If a server is heavily loaded or if disk performance is not optimal, increasing the ESE buffer improves overall system performance. Depending on your configuration, you may have to increase or reduce the size of this buffer to obtain the best overall performance.

For more information about how to adjust these settings, see Microsoft Knowledge Base article 815372, "How to Optimize Memory Usage in Exchange Server 2003" (https://go.microsoft.com/fwlink/?LinkId=3052&kbid=815372).