The Microsoft article "How to Gather Data to Troubleshoot Exchange Server 2003 Virtual Memory Issues" (http://support.microsoft.com/?kbid=823150) provides guidance about the information you need to gather to troubleshoot Exchange virtual memory problems. The article recommends that you run VaDump against store.exe because it's the most memory-intensive Exchange process. VaDump requires that you provide the PID for the process you want to debug, so use Task Manager to obtain the PID, as I described earlier. In Figure 3, the PID for the Store process is 4368. To capture the Store process that has a PID of 4368, use the following command:
vadump -v -p 4368 > f:diagnosis\va_store_23mar2004
.txt
VaDump doesn't generate a log file by default, so you'll need to use the redirection symbol (>) to generate a log file that PSS can analyze. I recommend that you give the dump file a meaningful name that includes the process name and the date of the VaDump session, such as the name I used in the preceding example. The -v switch directs VaDump to capture verbose information.
Gathering Performance Monitor Information
Performance Monitor can help you diagnose the root causes of Exchange crashes, especially in cases of memory leaks and virtual memory fragmentation, because it lets you see how the server is performing over time. The Microsoft article "How to Create a Log Using System Monitor in Windows 2000" (http://support.microsoft.com/?kbid=248345) describes how to configure Performance Monitor to log diagnostic information. To troubleshoot Exchange problems, you'll want to set up Performance Monitor to log the counters that Web Figure 2 lists.
Don't create Performance Monitor logs on the server that you're monitoring. If the server is rebooted, you'll have to manually restart performance monitoring. Also, if you run Performance Monitor on a production server and the server crashes or hangs, the server won't be able to send a notification message. If you have a spare machine, set up Performance Monitor on a workstation running XP. XP's version of Performance Monitor (called System Monitor) lets you use additional tools to automate performance monitoring. See the Microsoft article "Description of the Windows XP Logman.exe, Relog.exe, and Typeperf.exe Tools"
(http://support.microsoft.com/?kbid=303133) for information about these tools.
Also ensure that adequate disk space is available. The size of the log files depends on the number of counters you monitor and the logging time interval. Performance logs can become quite large (up to 500MB for a 24-hour logging period).
Diagnosing Memory Leaks
A memory leak occurs when a process requests memory and doesn't release the memory back to the OS when the process finishes. Over time, this occurrence exhausts all available memory, causing the system to crash. Some common causes of memory leaks include the following:
- Processes from an application are leaking because of a leak in a program.
- A device driver is leaking memory in kernel mode. In this scenario, the root cause of the problem won't be Exchange; a device driver associated with a hardware device is consuming memory.
- Malicious users are directing Denial of Service (DoS) attacks against a server to try to exhaust system resources such as memory or disk space.
When a system crashes, a blue screen with the message STOP 0x0000001E (0xC0000044) "STATUS_QUOTA_EXCEEDED" signals a memory leak. Microsoft provides the poolmon.exe tool to troubleshoot memory leaks. The tool is part of the Support Tools on the Windows 2003 and Win2K installation CD-ROM.
Use Poolmon to perform an audit of the device drivers and third-party products installed on the server. Compare the installed versions with the most recent release versions to see whether a newer version exists. Contact the vendor to see whether a newer version of the application or driver fixes a memory-leak problem. As a best practice, you should upgrade layered applications and device drivers regularly so that memory leaks and other problems are fixed as newer releases become available.
Diagnosing Virtual Memory Fragmentation
A common cause of instability in early Exchange 2000 deployments was virtual memory fragmentation. Microsoft released an updated version of the Store in Exchange 2000 Service Pack 3 (SP3) that improved virtual memory usage. The Windows & .NET Magazine article "Monitoring Virtual Memory" (November 2003, InstantDoc ID 40458) describes how to configure Performance Monitor to log information relevant to memory allocation. The list of performance counters in Web Figure 2 includes the relevant memory allocation counters.
Be Prepared
The tools and techniques I've described will help you troubleshoot Exchange stability and performance problems. Before you use these procedures in production, I recommend that you practice them on a test server. You can use MPS_Reports and VaDump with no service disruption; running ADPlus in hang mode locks out processes, so use it with caution. Also, make sure device-driver revision levels and third-party software versions are up-to-date to help prevent memory leaks. Your users will benefit if you have the necessary tools and preparation for quickly diagnosing and fixing Exchange problems.
End of Article
Prev. page
1
2
[3]
next page -->
