Analyzing and Monitoring Core Elements

The capacity analysis and performance optimization process can be intimidating because there can be an enormous amount of data to work with. In fact it can easily become unwieldy if not done properly. The process is not just about monitoring and reading counters; it is also an art.

As you monitor and catalog performance information, keep in mind that more information does not necessarily yield better optimization. Tailor the number and types of counters that are being monitored based on the server's role and functionality within the network environment. It's also important to monitor the four common contributors to bottlenecks: memory, processor, disk, and network subsystems. When monitoring Exchange Server 2003, it is equally important to understand the various Exchange roles to keep the number of counters being monitored to a minimum.

Memory Subsystem Optimizations

As with earlier versions of Windows, Windows Server 2003 tends to use the amount of memory that you throw at it. However, it outperforms its predecessors in terms of how efficiently memory is managed. Nevertheless, fine-tuning system memory can go a long way toward making sure that Exchange has adequate amounts of memory.

Memory management is performed by Windows Server 2003 and is directly related to how well applications such as Exchange Server 2003 perform. Exchange Server 2003 also has greatly enhanced memory management and the way it uses virtual memory. This reduces memory fragmentation and enables more users to be supported on a single server or cluster of servers.

With the Performance Monitor Console, there are a number of important memory-related counters that can help in establishing an accurate representation of the system's memory requirements. The primary memory counters that provide information about hard pages (pages that are causing the information to be swapped between the memory and the hard disk) are

• Memory—Pages/sec The values of this counter should range from 5–20. Values consistently higher than 10 are indicative of potential performance problems, whereas values consistently higher than 20 might cause noticeable and significant performance hits.

• Memory—Page Faults/sec This counter, together with the Memory—Cache Faults/sec and Memory—Transition Faults/sec counters, can provide valuable information about page faults that are not committed to disk. They were not committed to disk because the memory manager allocated those pages to a standby list, also known as transition faults. Most systems today can handle a large number of page faults, but it is important to correlate these numbers with the Pages/sec counter as well to determine whether Exchange is configured with enough memory.

Figure 33.4 shows some of the various memory-related and process-related counters.

Improving Virtual Memory Usage

Calculating the correct amount of virtual memory is one of the more challenging parts of planning a server's memory requirements. While trying to anticipate growing usage demands, it is critical that the server has an adequate amount of virtual memory for all applications and the operating system. This is no different for Exchange Server 2003.

Virtual memory refers to the amount of disk space that is used by Windows Server 2003 and applications as physical memory gets low or when applications need to swap data out of physical memory. Windows Server 2003 uses 1.5 times the amount of RAM as the minimum paging file size by default, which for many systems is adequate. However, it is important to monitor memory counters to determine whether this amount is truly sufficient for that particular server's resource requirements. Another important consideration is the maximum size setting for the paging file. As a best practice, this setting should be at least 50% more than the minimum value to enable paging file growth, should the system require it. If the minimum and maximum settings are configured with the same value, there is a greater risk that the system could experience severe performance problems or even crash.

The most indicative sign of low virtual memory is the presence of 9582 warning events logged by the Microsoft Exchange Information Store service that can severely impact and degrade the Exchange Server's message-processing abilities. These warning events are indicative of virtual memory going below 32MB. If unnoticed or left unattended, these warning messages might cause services to stop or the entire system to crash.

To get an accurate portrayal of how Exchange Server 2003 is using virtual memory, monitor the following counters within the MSExchangeIS object:

• VM Largest Block Size This counter should consistently be above 32MB.

• VM Total 16MB Free Blocks This counter should remain over three 16MB blocks.

• VM Total Free Blocks This value is specific to your messaging environment.

• VM Total Large Free Block Bytes This counter should stay above 50MB.

Other important counters to watch closely are

• Memory—Available Bytes This counter can be used to establish whether the system has adequate amounts of RAM. The recommended absolute minimum value is 4MB.

• Paging File—% Usage % Usage is used to validate the amount of the paging file used in a predetermined interval. High usage values might be indicative of requiring more physical memory or needing a larger paging file.

Monitoring Processor Usage

Analyzing the processor usage can reveal invaluable information about system performance and provide reliable results that can be used for baselining purposes. There are three major Exchange-related processor counters that are used for capacity analysis of an Exchange Server 2003:

• % Privileged Time This counter indicates the percentage of non-idle processor time spent in privileged mode. The recommended ideal for this value is under 55%.

• % Processor Time This counter specifies the processor use of each processor or the total processor use. If these values are consistently higher than 50–60%, consider upgrade options or segmenting workloads.

Monitoring the Disk Subsystem

Exchange Server 2003 relies heavily on the disk subsystem and it is therefore a critical component to properly design and monitor. Although, the disk object monitoring counters are by default enabled in Windows Server 2003, it is recommended that these counters be disabled until such time that an administrator is ready to monitor them. The resource requirements can influence overall system performance. The syntax to disable and reenable these counters is as follows:

							diskperf –n (to disable)
diskperf –y [\computer_Name] (to reenable)

Nevertheless, it is important to gather disk subsystem performance statistics over time.

The primary Exchange-related performance counters for the disk subsystem are located within the Physical and Logical Disk objects. Critical counters to monitor include, but are not limited to, the following:

• Physical Disk—% Disk Time This counter analyzes the percentage of elapsed time that the selected disk spends on servicing read or write requests. Ideally this value should remain below 50%.

• Logical Disk—% Disk Time This counter displays the percentage of elapsed time that the selected disk spends fulfilling read or write requests. It is recommended that this value be 60–70% or lower.

• Current Disk Queue Length (Both Physical and Logical Disk Objects) This counter has different performance indicators depending on the monitored disk drive (Database or Transaction Log volume). On disk drives storing the Exchange Database, this value should be below the number of spindled drives divided by 2. On disk drives storing transaction log data, this value should be below 1.

Monitoring the Network Subsystem

The network subsystem is one of the more challenging elements to monitor because there are a number of factors that make up a network. In an Exchange messaging environment, site topologies, replication architecture, network topologies, synchronization methods, the number of systems, and more are among the many contributing factors.

In order to satisfactorily analyze the network, all facets must be considered. This will most likely require using third-party network monitoring tools in conjunction with built-in tools such as the Performance snap-in and Network Monitor.