We’ve been in the situation where our PC, a friend’s, or maybe even a customer’s PC is running slow or acting strange, and we want to figure out quickly what is the root cause.  Often the first place, we look is the Task Manager for the number of running processes, then tell user to run less programs.  While this is often an acceptable solution, it ignores the possibility of an issue going on at a lower level – this is where we start to compare our performance baseline to the current system performance.  You did make a baseline right?  No?  That’s why we’re here then.

Performance baselines are one of those annoying things we all should do like getting the car’s oil changed, taking showers, going to the doctor, paying taxes, and such.  Yet, many people never create a baseline even though it only takes about ten minutes for the initial baseline and would save hours of wasted time down the road when problems occur.  In Windows 7 and Server 2008, the simplest way to create a basic baseline is already provided to us via Data Collector Sets (DCSs).  Data Collector sets are predefined collections of system information, configuration settings, and performance data, into a single point for reference – based on the results of the DCSs, scripts can be executed, alerts generated, WMI tasks scheduled. 

There are several ways to get to the Performance monitor.  Probably the easiest is typing “Performance monitor” into the search box of the start menu.  Performance monitor can also be reached through Computer management, typing compmgmt.msc into the run box, by typing perfmon into the run box, or putting Performance monitor into the search box. .

Once performance monitor opens, you’ll be greeted with a screen like the one above – note, I’ve drilled down through the Data Collector Sets to the System Performance DCSs.  From here, right click on the System Performance DCSs and choose “Start.”  The System Performance DCSs will take samples every second for 60 seconds.   During the sampling period it looks at process, physical disk, processors usage, processor performance, Memory, System, and Network Interface counters.  Once the DCSs finishes, the system will create a report under Reports->System Performance.  The reports will be named in the following format: PC_NAME_YYYYDDMM-xxxx where xxxx is an incrementing counter for each report run on that specific date.  

The report is broken down into 7 sections: Summary, Diagnostic Results, CPU, Network, Disk, Memory, Report Statistics.  Most of the sections are pretty well documented and straight-forward, so I’m just going to cover some of the highlights. 

The summary section provides us with a high level overview of how the system is running, with Total CPU%, Most active disk by IO, Disk queue length, Memory utilization, total memory, and network utilization.  From these counters, we can determine many things.  If we look at Disk Queue Length we can determine how well our internal hard drives are handling the loads placed on them.  The optimal value for disk queue length is anything less than twice the number of drive spindles – basically, less than 2 times the number of hard drives.  In my example, there is only one hard drive with a queue length of two.  This means my drive is handling the current request without any serious performance problems.  If this value is three or above it would mean the hard drive is not able to keep up with the number requests, resulting in slow system performance.  If my drive is having problems handing requests, there are a few ways to handle the performance issue.  More drives could be added and files requiring intensive disk activity could be moved to the new disks, or a the drive could be replaced with a higher RPM hard drive. Memory utilization tells us how much memory was being used during the DCSs capture, and which process was using most the memory.  In my case, my system was at 42%, with svchost being the top process.  This is what I expected, since I was running VirtualPC, and running several other programs at the same time. 

The rest of the sections are pretty well laid out, and Microsoft has added tooltips to many of the things which may need more clarification or alert us to performance issues.  Now, we know how to create a basic performance baseline using the built-in Windows 7 Data Collector Set called System Performance, we can more accurately diagnose the sources of poor system performance. Ideally, a baseline should be created several times for a system during low usage, normal usage, and peak usage.  For the average end user, its ok to have a low usage baseline to troubleshoot from and to know where to look to get more information when problems do occur with performance. 

Below is an example of a new Server 2008 R2 box I took a baseline on during a burn-in test – note how the DCSs’ report automatically flags the high CPU load with pink highlighting and with a red tooltip flag on the far right hand side.