Solving computer performance issues can be one of the most difficult challenges faced by an IT professional. They are very difficult to define and even more difficult to analyze and solve.
Performance often depends on the perspective of the user doing the complaining. I have seen some organizations complain about a one- or two-minute client logon time, while others are happy if it is only five minutes. To a degree, we all get used to computer performance because it's easier to adapt to it than to have it fixed.
There are, however, some powerful analysis tools available that will help your staff monitor performance, find the source of performance problems and occasionally catch a problem proactively. The best thing about the tools I'm about to describe is that they are free.
Performance Monitor (PerfMon)
PerfMon has been around in some form since Windows NT. It is found under Diagnostics in the Windows 2008 Server Manager console. Windows 2008 R2 changed the folder structure of Diagnostics, but PerfMon is still there. PerfMon has the ability to capture "counters" or data points for a wide variety of objects and sub-objects or instances. For instance, we typically capture objects for Memory, LogicalDisk, Processor, System, TCP, Cache, NetworkInterface, Server, ServerWorkQueues and other counters. Applications like Exchange and SQL have their counters as well.
Capture can be filtered to specific instances, such as Page faults/sec, pool paged bytes, pool nonpaged bytes, under the Memory object. Personally, I like to cast a wide net, so I always capture all instances of the objects just noted. The trick to using PerfMon effectively is to establish a baseline so you can tell if performance has degraded in a subsequent capture. Using the counters noted, configure for a 30-second interval for 48 hours.
PerfMon capture takes very little if any overhead except for the Process object. Typically, it's a good idea to specify which process you want rather than to monitor all of them. The counters collect data whether PerfMon is running or not. All PerfMon does is display the data in a GUI so you need not worry about PerfMon further reducing performance.
Once you have the data, you must analyze it. Here are some tools that can help.
Performance Analyzer of Logs (PAL)
PAL is truly a pal to anyone doing PerfMon analysis because it has a lot of built-in intelligence. It uses standard PerfMon .blg files as input and you can select from a variety of analysis methods to sort the data. For instance, I use Active Directory analysis so it looks at the data from an AD point of view. PAL generates the reports in HTML format, showing the data in tables and graphs, but it also flags any values that violate certain best practice standards.
Figure 1 shows the chart format of Processor % Privileged Time counter with the date and time that the samples were taken. Figure 2 shows PAL's intelligence providing alerts that the data is in a warning (yellow) state for Processor 1. Engineers naturally must use their knowledge to know how to evaluate their results.
Xperf is a part of Microsoft's Windows Performance Analysis Tools and is similar to PAL. It presents data in a clear, organized fashion but is more flexible than PAL.
Figure 3 shows two sets of data that were collected by xperf and overlaid. Here we see CPU usage compared to Disk I/O. Overlays like this help draw conclusions so high that CPU usage can be shown to occur when disk I/O spikes, narrowing the causes of the CPU spike. Xperf can also create tabular data. For example, a chart can be generated listing all of the installed drivers and showing the CPU time each is taking. This way we can point to a specific driver as the cause of the spike.
Microsoft Exchange Best Practices Analyzer (ExBPA)
The Microsoft Exchange Best Practices Analyzer is a must for doing Exchange Server analysis, i.e., general troubleshooting or performance. There are several "scans" to choose from but I typically use the health check. When complete, it generates a report (which must be read in ExBPA). The report can be filtered to show only critical errors or all errors and warnings. Figure 4 shows the results of an ExBPA scan. You should run it on each Exchange Server, but it will show connectivity issues with AD domain controllers and other Exchange servers.
Just like the other technologies I've described here, ExBPA is a tool, not a solution. Each item in the report is something to investigate. Fortunately, Microsoft gives a description of the event as well as a link to a KB or TechNet article for further study. It is a good way to start when troubleshooting any Exchange Server issue.
Active Directory Best Practice Analyzer (Windows Server 2008 R2)
Having spent the past 10 years troubleshooting AD issues, I have eagerly waited for the ADBPA. While Microsoft has a paid service for this, there was not a tool like ExBPA that would do the AD analysis. Unfortunately, this tool only works on Windows Server 2008 R2 domain controllers. Given that R2 has yet to be released, the tool doesn't help us right now – but at least hope is on the horizon.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.
This was first published in July 2009