Administrators have many responsibilities when it comes to ensuring the reliability and performance of their servers. But sometimes their responsibilities get overshadowed by just trying to maintain a set level of performance. If their server performance slows down or begins to degrade they must be able to know where to go looking to correct the behavior before it begins to adversely impact their end user community.

One of those areas that can present performance problems is in the area of memory. And as one of the main components of server performance – CPU, I/O and memory – lack of memory resources can be fairly easily solved by purchasing and installing more memory. But when more memory is not the answer then the troubleshooting process can be more time consuming as there are more aspects of memory usage which must be examined.

Many times the memory performance problems don’t show up until the software applications – such as Outlook – have been upgraded. Some administrators have reported performance problems with paged and non-paged pool memory as the number of Outlook 2007 client have been added within the organization.

To solve this problem it is necessary that the paged pool memory used by client connections to the Exchange server be reduced. This can be accomplished by reducing the size and number of access tokens. Additionally, the client connections can also be distributed and managed so as to optimize performance.

One indication that kernel memory resources are being depleted is when the server becomes slow or refuses additional requests and connections. Other signs that the server is running out of memory is if applications are beginning to fail. And if connections to the server are unsuccessful then an error such as error code 1450, “Insufficient System Resources” may be returned. The worst case scenario is one that administrators and end users are all too familiar with which is the hated blue screen kiss of death.

As with diagnostics of most system problems the error logs should always be checked for any tell-tale messages. Such messages can be found in the system log and may be reported as in the following error events:

Event ID: 2019
Source: SRV
Description: The server was unable to allocate from the system nonpaged pool because the pool was empty.

Event ID: 2020
Source: SRV
Description: The server was unable to allocate from the system paged pool because the pool was empty.

Event ID: 2000
Source: SRV
Description: The server’s call to a system service failed unexpectedly.

If the server continues to exhibit performance problems a temporary solution is to just reboot the server. Keep in mind that under standard load, there should be approximately 50 MB of available paged pool memory. If the available paged pool memory drops below 30 MB then an administrator should take steps immediately to free up memory on the server.

Other factors affecting the size of the paged pool memory include boot switches such as /USERVA and /3GB, registry settings, and, as already mentioned, physical memory. During Windows startup the system statically allocates paged pool memory. This is the place that administrators can customize how much memory is allocated. Each process is allocated memory based on the /Userva= switch. For example, if an administrator sets /3GB and /Userva=3030 then 3030MB of memory is reserved for the process space. This is different than just using the /3GB switch by itself which will reserve 3072MB. Using the /3GB and /Userva=3030 will save 42MB that can be used to increase the kernel memory space.

Another diagnostic approach is to review the number of connections per client to the Exchange server.  An administrator can use the “netstat” command to ascertain the number of connections. If there are more than twenty connections from a one IP address to the Exchange server over an extended length of time then this will be an area for further investigation.

Lastly, administrators can apply a hotfix for Exchange 2003 SP2 that is used to optimize the use of client tokens. Up to one-third of the token memory consumption that is related to MAPI clients can be reduced by applying this hotfix. Administrators should only apply this hotfix if their servers are experiencing paged pool memory depletion issues that are caused by token allocations. More information about hotfix can be found by reviewing the following article number, 912480, in the Microsoft Knowledge Base (http://support.microsoft.com/kb/912480/).