- Tuning Exchange 2003
- Deprecated Exchange 2000 Tuning Parameters
- Exchange 2003 Tuning Parameters
- Exchange 2003 Tools
- Resources and Links
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Deprecated Exchange 2000 Tuning Parameters
Although Exchange 2000 did not include the Performance Optimizer, there were still a variety of registry settings and other changes you could make to tune Exchange or change its behavior.1 Any changes you made to tune or alter the behavior of Exchange 2000 need to be reviewed before implementing Exchange 2003. Indeed, most of them are no longer needed in Exchange 2003, but more importantly some of them can cause problems when used on an Exchange 2003 system. Therefore, before upgrading any Exchange 2000 servers to Exchange 2003, you should review the following information.
Exchange 2000 Clusters
Exchange 2000 included two tuning registry parameters specific to EVSs running in a cluster. Both parameters were designed to prevent a very busy SMTP resource in an EVS from starving other resources in the EVS such as IMAP4 and POP3. The tuning parameters were the SMTP % of threads and Additional threads per processor values, which were represented in the registry as follows.
Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing Value: MaxPercentPoolThreads Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing Value: AdditionalPoolThreadsPerProc
MaxPercentPoolThreads was used to control the percentage of threads used by the SMTP service, and AdditionalPoolThreadsPerProc enabled you to control the number of additional threads that could be spawned on a per-processor basis. If you added either of these registry entries to your Exchange 2000 cluster, you should remove them prior to upgrading your EVSs to Exchange 2003.
Directory Service Access Cache
As the name suggests, Directory Service Access (DSAccess) is an internal component in Exchange that controls how all Exchange components access Active Directory. The primary function of DSAccess is to keep tabs on various directory-related things. For example, DSAccess discovers the Active Directory topology and detects the state of domain controllers and global catalog servers (up or down). In addition, all directory queries are routed through DSAccess, such as recipient resolution, configuration setting look-ups, and others. As part of its job, DSAccess maintains an in-memory cache of the results of some of these queries so that if the same information is requested twice, it can be retrieved from the DSAccess cache instead of through another LDAP query against Active Directory. The size of the in-memory cache is configurable, in that you can set a maximum size for various cached items.
Many administrators found that on larger Exchange 2000 servers, the out-of-the-box values for the maximum cache size for recipient look-ups and the maximum cache size for configuration look-ups were not always optimized for their servers. On systems with an undersized DSAccess cache, it was common for local message delivery and/or address book resolution to be slow. Once the maximum size of the recipient cache was increased and the size of the configuration cache was decreased, performance would improve. The DSAccess cache tuning parameters for the configuration data cache and the user object cache were represented in the registry as follows.
Location: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0 Value: MaxMemoryConfig Location: HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0 Value: MaxMemoryUser
In Exchange 2000, each cache pool (e.g., the configuration cache, the recipient cache, and so on) was initially set at 25MB in size. To improve performance, the default values for the configuration and recipient caches have been optimized in Exchange 2003. The configuration data cache, which more often than not never needed anywhere near 25MB, now defaults to 5MB. The user object cache, which was often undersized for larger systems, now defaults to 140MB. Therefore, you should remove the MaxMemoryConfig and MaxMemoryUser registry entries prior to upgrading from Exchange 2000 to Exchange 2003.
Extensible Storage Engine Heaps
Like other operating systems, Windows includes a process-wide heap manager that handles memory operations for all processes. Each time a process instantiates, a default heap (called the process heap) is created for that process. Programs or modules loaded in that process can also create additional heaps if needed. Exchange is one program that does this.
In Exchange 2000, each time the Exchange information store was started, the STORE.EXE process got its initial process heap. Then, a module loaded in the information store process—ESE.DLL—allocated four JET heaps for each processor present in the system. Although these heaps were separate pools of memory in the information store process, they were collectively referred to as the ESE multiheap. On a single CPU system, ESE allocated four JET heaps. On a dual CPU system, it allocated eight; on a quad system, it allocated sixteen; and so forth. When Exchange 2000 was installed on systems with four or more CPUs, it was found that the ESE multiheap caused excessive virtual memory consumption, which in turn led to performance problems. Ironically, the problem was worse on systems with a large amount of resources installed (multiple CPUs and multiple gigabytes of memory).
To correct this problem, Microsoft recommended that customers with large Exchange 2000 servers add the following registry entry to their systems.
Location: HKLM\Software\Microsoft\ESE98\Global\OS\Memory Value: MPHeap parallelism Type: REG_SZ
The value data setting depended on the number of CPUs present in the system, and if you added or removed CPUs to the system in scale-up or scale-down procedures, you had to manually readjust this setting. Exchange 2003 now automatically calculates the optimum number of heaps to allocate based on the unique specifications of each system. Therefore, you should remove the MPHeap parallelism registry entry from Exchange 2000 servers prior to upgrading to Exchange 2003.
Initial Memory Percentage
In Chapter 7, I wrote about virtual memory and the importance of monitoring it on an Exchange server. It is especially important to watch on Exchange servers for two reasons: (1) the more virtual memory available, the greater the load that can be handled; and (2) performance problems can occur (especially on Exchange clusters) when virtual memory becomes too fragmented. When virtual memory becomes too fragmented, Exchange logs the following event in the Application event log.
Event Type: Error Event Source: MSExchangeIS Event Category: Performance Event ID: 9582 Date: 10/10/2003 Time: 3:42:38 PM User: N/A Computer: EX2K3 Description: The virtual memory necessary to run your Exchange server is fragmented in such a way that normal operation may begin to fail. It is highly recommended that you restart all Exchange services to correct this issue.
As this event log entry indicates, restarting all Exchange services was needed in order to correct the problem. If this happened regularly, you ended up restarting Exchange frequently, and both your users and management probably wondered why their e-mail server was so unreliable.
To combat the virtual memory fragmentation problem, Microsoft introduced the following registry entry and recommended value in Exchange 2000 that hard-coded Exchange's initial memory allocation to 10% of the total amount of physical memory in the system.
Location: HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Value: Initial Memory Percentage Type: REG_DWORD Value Data: 0xa (hex)
By starting out with this initial allocation and then growing from there, virtual memory fragmentation would not occur as often. As I mentioned in Chapter 7, Exchange 2003 includes support for special startup switches in Windows 2000 Advanced Server and Windows Server 2003 that help reduce virtual memory fragmentation, and Microsoft made additional changes to help prevent virtual memory fragmentation in Exchange clusters. As a result, the Initial Memory Percentage registry value is no longer needed. Moreover, because it does not work on an Exchange 2003 server, you should remove this value from all Exchange 2000 servers prior to upgrading to Exchange 2003.
Log Buffers
As a database that passes the ACID (Atomic, Consistent, Isolated, and Durable) test for transaction-based activity, Exchange first writes all activity to transaction logs and then commits the transactions to the database file. But before Exchange writes anything to a transaction log, it first holds the information in memory in an area called log buffers. Unlike the settings mentioned so far, which are registry values, the size of the log buffers is controlled by an attribute of the information store object in Active Directory—msExchESEParamLogBuffers.
Throughout the product life of Exchange 2000, the recommended best practice setting for the msExchESEParamLogBuffers attribute changed a few times. Out of the box, it was set to 84, which was determined to be too low for heavily used servers, especially clustered back-end servers. When Service Pack 2 for Exchange 2000 was released, Microsoft recommended that customers adjust this value from 84 to 9000. When Service Pack 3 was released, Microsoft recommended that customers readjust the value down from 9000 to 500. Because the out-of-the-box value for msExchESEParamLogBuffers in Exchange 2003 is 500, you will want to use the ADSI Edit tool to delete any manual tuning entries (even if set to 500) and return the value for this attribute back to <Not Set>.
Maximum Number of Open Tables
Although it typically provided little bang for the buck, another way to combat memory fragmentation and allocation issues in Exchange 2000 was to reduce the maximum number of open tables that can be used by Exchange. Exchange 2000 cached data about folders that were not currently accessed, a behavior that in some cases contributed to virtual memory fragmentation. To reduce the cache's impact on virtual memory fragmentation, the msExchESEParamMaxOpenTables attribute in Active Directory would be lowered. Typically this change was made only at the direction of Microsoft PSS; however, it was a documented value, so many administrators have made this change. Certainly you'll want to check your own storage groups to see if the value exists. It was often used in tandem with the /3GB switch in the Windows BOOT.INI file, so it's a pretty safe bet that if you are using /3GB, you probably also have this value set.
msExchESEParamMaxOpenTables is an attribute of storage groups. The recommended value for this attribute also changed periodically throughout the life of Exchange 2000. In Service Pack 2, the default value was automatically set to 42500 on four-way systems and 85000 on eight-way systems. In Service Pack 3, this was changed to 13800 and 27600, respectively. If you do find a value set for msExchESEParamMaxOpenTables on any Exchange 2000 storage group, regardless of its value you will want to return the value for this attribute back to <Not Set> prior to upgrading to Exchange 2003.
Outlook Web Access—Content Expiry
Like Exchange 2000 OWA, the Exchange 2003 version of OWA is comprised partially of static files (such as image files, scripts, and so forth). Typically these files were changed only when administrators either customized one or more OWA files or installed an Exchange service pack. Despite the fact that the files remained unchanged for long periods, they were marked as expiring one day after being fetched by the Web browser. Because the files expired each day instead of being retrieved from the browser cache, they were pulled down every day by every user from the OWA server—the same file, the same user, different days. To stop this insanity, Microsoft recommended that the virtual directory that served the static files—Exchweb—be configured with a much longer content expiry (a year or so).
While this method worked to reduce the load on your network and your OWA server in Exchange 2000, it doesn't work in Exchange 2003. In fact, on Exchange 2003 servers, the Exchweb virtual directory should always have its content expiration set to 1 day. It should not be disabled, and it should not be set to anything greater than 1 day.
SMTP Service Tuning
On busy Exchange 2000 systems that sustained large SMTP message queues (e.g., an average of 1,000 or more), performance constraints were encountered because of a default setting on the SMTP service of a maximum of 1,000 file handles. Each time the SMTP transport stack on an Exchange 2000 (or Exchange 2003) server receives a message, it is streamed out to the file system, where it waits to be routed to its destination. To write it to the file system, the SMTP transport stack obtains a file handle and then passes the message into that handle. Because Exchange 2000 defaulted to a maximum of 1,000 file handles, the SMTP service could write only 1,000 simultaneous messages to the file system.
To improve performance for these large systems, three registry entries were often simultaneously adjusted to increase the maximum number of file handles that could be opened by the SMTP service (so that more messages could be processed) and to decrease the number of open file handles for the installable file system, another Exchange component (to avoid running out of memory when the queue is large). These registry values, which did not exist by default and therefore needed to be added manually, are listed here.
Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing Value: MsgHandleThreshold Type: REG_DWORD Location: HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing Value: MsgHandleAsyncThreshold Type: REG_DWORD Location: HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters Value: FileCacheMaxHandles Type: REG_DWORD
The MsgHandleThreshold and MsgHandleAsyncThreshold entries would be set to the same value (some value greater than 1000), and the FileCacheMaxHandles entry would be reduced from 800 to 600.
Exchange 2003 dynamically calculates the appropriate settings for SMTP files handles, so these settings are no longer needed. Therefore, before upgrading any Exchange 2000 servers with these settings to Exchange 2003, you should delete the entries from the registry.