Exchange Monitoring: A Few "Kernels" of Wisdom

In our performance-tuning formula MIC, the M stands for memory. It's the first letter because memory issues can be at the root of what, at first, appear to be I/O problems, CPU bottlenecks, etc. Here we focus on the most basic of basics: kernel memory, the allocation of which can have a profound effect on Exchange performance.

Supply and Demand: The Market for System Page Table Entries

High utilization of kernel memory may cause severe performance degradation and instability. Indicators of this problem are:

	1.	High page-ins or slow response, symptomatic of low physical memory;
	2.	High paging rates, high page file usage, or slow response, symptoms that committed memory is significantly higher than physical RAM;
	3.	Page pool leaks;
	4.	Low number of available system page table entries (under 3,500).

On Windows Server 2003, the main recourse to address kernel memory shortage is to set aside more memory. Use the /USERVA switch parameter, in conjunction with the /3GB switch, in the Boot.ini file. For details, see Microsoft's support article #810371 .

Last—and least—reduce the competition for system page table entries by using a generic video driver, or by using the /VGA switch in your Boot.ini file to force the system to boot in 800x600 VGA mode.

Mail Queues: No One Likes Waiting in Line

The size of mail queues is another condition that may cause kernel memory-related performance problems, even outages. We recommend that SMTP queues, for instance, contain no more than 1,000 messages. Mail queues require Exchange services to keep files open, which uses up paged and non-paged pool memory. You will improve performance if you keep paged pool memory under 175 MBs, and non-paged under 100 MB.

Quite a number of situations can cause the build-up of messages in the various queues. You can get a toehold on this extensive (and expansive) subject by reading Microsoft's TechNet article "Troubleshooting Mail Flow and SMTP" . We'll try to save you some research by pointing out likely culprits for long SMTP queues:

In the local queue, a high number of messages may be caused by a delay in consulting Active Directory or in handing messages off for local delivery, or by dismounted Exchange databases.

In the remote queue, build-ups may be caused by problems with the network, or with remote Exchange servers.

Performance Reports: Those Gremlins Can't Hide

Using a combination of performance reports, you can detect exactly where the bottlenecks or throughput constraints are. During a peak period (or several), run system graphs for:

	1.	CPU utilization and queue length (if high, then run a graph of CPU percentage by mode: user, system, etc.);
	2.	Physical memory percentage used;
	3.	Page file percentage used;
	4.	Paging rates (page faults and page ins);
	5.	Committed bytes vs. commit limit;
	6.	Disk utilization; and
	7.	Disk storage.

Evaluate these system graphs in conjunction with Exchange graphs for message store, SMTP queue length, etc. to provide a picture of system and Exchange load, and how they behave together. Some simple analysis should point to areas where throughput can be increased by either adding resources or reducing/balancing load.

As Always, Your Mileage May Vary

We've presented some rules of thumb—starting points for tackling problems in your particular Exchange environment. Fine-tuning memory usage is not for the faint-of-heart, but it is essential to secure the best performance of your mission-critical Exchange systems. Do it well and your users will thank you. Okay, they won't thank you, but they'll have less cause to complain.

In our next issue, we will explore use of virtual memory by the Exchange store.

Learn more ...

Next month, Exchange Monitoring Part 3: Who's Minding the (Exchange) Store?...