So far in this series, I’ve explained that there are basically two areas you have to worry about when optimizing an Exchange Server environment: the network’s performance and the Exchange Server’s performance. In part one, I explained how the network’s topology affects Exchange’s performance. In part two, I discussed how important it is to optimize the disk subsystem on your Exchange servers.
However, there is much more to optimizing an Exchange Server than simply optimizing the disk subsystem. In this Daily Drill Down, I’ll explain how memory and processing power affect Exchange’s performance. I’ll also discuss some other factors that contribute to slowing down Exchange, and how to get around those factors.
At first, it may seem pointless to read this Daily Drill Down. After all, you can just install an insane amount of memory and an ungodly amount of processing power into your server and Exchange will run great. No matter how much memory or processing power your server has, however, you can still use the techniques I’ll be discussing to make your server run even better. Remember that optimization is as much about reducing unnecessary server loads as it is about adding computing power.
Few things, including a slow processor, can slow an Exchange Server down as much as having insufficient memory. To understand why this is the case, think about the way that Windows NT works. Windows NT relies on a machine’s physical memory for as many processes as possible. When a machine’s physical memory becomes full, however, Windows NT stores data that’s destined for memory on the hard disk in a file called the page file (sometimes called a swap file). When the operating system needs to access a piece of information from memory, but that information is stored in the page file, Windows NT moves some data that’s not being used by the current process from memory to the page file. By doing so, the operating system frees up enough space in memory for the information that it needs to access. Windows NT then moves the necessary information from the page file to the memory where the operating system can use it. This process is called paging.
Paging is a slow process when compared to simply accessing data directly from memory. Remember that memory access is measured in nanoseconds while disk access is only measured in milliseconds. Not only is disk access slower than memory access, but the process of moving data back and forth between the two takes a lot of time as opposed to accessing the data from memory.
Although paging is a slow process from the computer’s standpoint, paging a single piece of information is barely noticeable from a user’s standpoint (on a fast machine). Paging is a normal process that happens fairly often. But even though paging a single chunk of data doesn’t eat up that much time, a poorly optimized server could end up paging millions of chunks of data at a time. Paging a lot of data takes a lot of time. Therefore, the idea is to minimize paging as much as possible.
So how do you know if your Exchange Server is paging data too often? There’s always the Performance Monitor. But even though the Performance Monitor is a good tool for fine-tuning, you won’t need it to spot a machine that’s paging excessively. You can tell if a machine is paging too often just by watching the hard drive activity light on your server and listening to the hard drive.
Excessive paging (typically known as thrashing) pretty much brings even the fastest machine to a standstill. If a machine is thrashing, it means that the memory is completely full and that the machine is trying to process much more information than it can comfortably handle. Remember that the process of paging involves reading from and writing to the hard disk. Not only does this process require hard disk time, it also requires processing power. A machine that’s thrashing will run extremely slowly because the memory is full, the CPU is busy trying to handle the constant paging operations, and the hard disk runs continuously. In fact, the best way to spot a machine that’s thrashing is to look for a hard disk that’s working very hard all the time.
The best cure for thrashing is to add memory to the machine. Increasing memory increases the amount of data that can be stored in memory before paging becomes necessary. If you’re trying to optimize a server that’s paging excessively, you’ll probably have to add a lot of memory. Adding a little bit of memory usually does little good since the additional memory fills up quickly and then the machine just starts paging again.
If you’ve optimized your disk subsystem and your server has plenty of memory, the next area that you need to concentrate on is processing power. In Exchange servers, the CPU is the third most likely component to become overloaded. There are basically two different schools of thought on how to best optimize Exchange through upgrading processors. Some books I’ve read suggest that you should upgrade to the fastest processor available, while other books suggest that you should use multiple processors within the server. The technique you use should depend on your individual server’s configuration.
In just about any environment, it makes sense to use the fastest processor available. Exchange Server is an absolute resource hog when it comes to processing power. After all, Exchange Server rides on top of Windows NT Server. Windows NT’s internal processes will always consume some of your processing power. Of course, Exchange Server requires processing power above and beyond what’s required by Windows NT. Additional factors, such as being a domain controller, can require even more processing power. As you can see, the faster the processor an Exchange Server has, the better it will run.
In some situations, though, it makes sense to go to a multiprocessor configuration. In other situations, adding a second processor is actually a bad idea. To understand why this is the case, you have to understand a little bit about the way that Windows NT interacts with a multiprocessor system. A lot of people assume that adding a second processor doubles the machine’s speed. Nothing could be further from the truth, however.
As you may know, most programs (including Exchange Server) that are written for Windows NT are composed of several threads. A thread is a unit of executable code. Often several threads are running simultaneously. To run a program across multiple processors, Windows NT must be able to run some threads on one processor and other threads on a different processor. Unfortunately, it’s not quite that simple. Remember that all of the threads that an application runs belong to a single program. This means that although the threads run independently of each other, they can’t function entirely independently.
Although this statement sounds contradictory, it really isn’t. For example, suppose you’ve got two threads running simultaneously. Now imagine that thread two needs a computed result from thread one. Thread two will stop until thread one provides it with the necessary information. Only then will thread two continue to run. As you can see, having multiple processors is rarely effective for a single application unless that application has been designed to take advantage of multiple processors.
Unfortunately, Exchange Server is primarily designed to run on a single processor. There are situations, though, in which it makes sense to use multiple processors with Exchange Server. One such situation is when other programs are running on your Exchange server. For example, suppose you had SQL Server running on your Exchange box. You could easily run Windows NT and Exchange on the first processor and run SQL Server on the second processor.
Even if Exchange Server is the only application running on a given machine, you’re not totally out of luck if you want to use multiple processors. Although the core Exchange Server modules don’t run well across multiple processors, there are some Exchange Server components that can be offloaded to a different processor. If your Exchange server is the central messaging hub in your organization, or if it uses connectors, then you can gain some increase in performance if you add a second processor.
There are a lot of types of connectors in Exchange Server. Since it’s often difficult to remember all of the types, I’ll outline the connectors that can take advantage of a second processor.
Perhaps the most common type of connector is the type used to link Exchange sites together. Whether you’re using a traditional site connector or an X.400 connector, you can take advantage of a second processor. You can also take advantage of an extra processor if your server uses an Internet mail connector.
Other times when a second processor can help include situations in which the Exchange Server uses a connector or protocol to interact with a foreign mail system. For example, the Microsoft Exchange Connector for Lotus cc: Mail can take advantage of a second processor. Likewise, you can use a second processor with the POP3, NNTP and HTTP protocols.
If your Exchange Server falls into one of the categories I’ve mentioned, and you decide to add a second processor, don’t expect to get a 100% performance gain. There are several reasons for this. For starters, a connector doesn’t usually require as much processing power as the core operating system does. If you use the second processor to offload a separate application—such as SQL Server—that requires lots of processing power, you still won’t get a 100% gain in processing power. Even if you have applications that consume enough processor time that they can max out both processors, the most you can hope for is about a 50% performance gain. That’s because a portion of each processor’s power is used for the task of assigning threads to each processor. Remember that on a single processor machine, Windows NT didn’t have to do this. Therefore, as you increase the machine’s power by adding processors, you also increase the machine’s workload exponentially.
If you’re disappointed by this fact, I do have some good news. You’re not limited to a mere two processors. Straight out of the box, Windows NT is set to run on machines that have one, two, or four processors. With a modified HAL (Hardware Abstraction Layer), Windows NT can handle up to 32 processors. Sure, each processor will still have to dedicate a good portion of its resources to load balancing, but the more processors you add the faster your machine will run, assuming that your applications are designed to handle the extra processors.
If you’re just running a basic Exchange installation and it doesn’t look like multiple processors will help you, you may be wondering if there’s anything you can do to speed up the processing. Regardless of whether you’re using one processor or multiple processors, I recommend using a really large L2 cache. On single processor models, a large L2 cache will reduce the processor’s wait time while data is being retrieved from memory. On multiprocessor models, a large L2 cache will help to improve overall throughput by reducing the load on your system bus.
In this Daily Drill Down, I’ve explained that memory, processing power, and server load are all factors that need to be looked at when optimizing Exchange Server’s performance. I addressed the issue of how each of these factors affects Exchange Server’s performance, and how to get around related performance problems.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.