Previously, I wrote a blog about excessive paging on Exchange 2007 servers due to a system wide working set trimming problem at http://blogs.technet.com/mikelag/archive/2007/12/19/working-set-trimming.aspx. Over time, I have been asked to consult on many cases that had to do either with high memory usage or a server that was paging excessive causing performance problems.
I've moved the recommendations here to make it easier to reference. Find below a listing of some of the top reasons why you may run in to these issues
Top Reasons for these issues
Exchange Server Update Recommendations - Last updated (05-12-10) Find below a list of recommendations to help alleviate the working set trimming issues that you may be running in to on Exchange 2007 Mailbox servers
If the above updates do not resolve the issue, find below some recommendations on where to go at this point.
Outlook Client Recommendations
Setting DBCache Recommendations (Updated 08/29/09)
There are extreme cases where setting DBCache makes sense when other applications on the server are competing for memory resources. This should only be done after exhaustive troubleshooting and under the supervision of Customer Support Services (CSS). Exchange is very good at handling its memory utilization, but other applications put a strain on Exchange’s Dynamic Buffer Allocation that could cause Exchange to not shrink it’s DBCache quick enough to prevent a working set trim operation.
If you need to set this for any reason, you can follow the steps in http://technet.microsoft.com/en-us/library/bb691304.aspx. Important: There have been cases where the value listed in the Technet documentation have been put on Exchange servers with negative performance effects as a direct result since the value did not fit their Exchange server configuration. It is very important that you calculate the amount of required DBCache following the recommendation in the documentation based on user load/profile and overall RAM on the server. You can look at Planning Memory Configurations to help calculate this. If you want a base to start without calculating the value, you can start at setting DBCache to 90% of overall RAM. You can then increment down in 10% increments down to 70%. If you are still having problems at 70%, you need to call Support Services for assistance to help you understand what other processes are causing memory problems with Exchange.
In some situations while monitoring performance of a server, you may find a time when a particular process is restarting or crashing over time. By default, in Performance Monitor, you cannot view Process ID (PID) values to determine if a process was restarted for whatever reason. This is apparent for IIS Application pools as these processes could frequently crash/restart throughout the day. With each new restart of a process, a different PID is generated, so it would be nice if you could see this happening in Perfmon.
Luckily, there is a way to do just that to append the PID number for each process, so that if the PID should change, you can easily detect this in Performance Monitor.
To show ProcessID's along with process names, add the following registry entry on the server
This needs to be implemented on the machine in which the perfmon is being taken from. For more information regarding this registry setting, see 281884