If you would like to read the next article in this series please go to Using Windows Performance Monitor to Baseline a Terminal Server (Part 1).
Windows Performance Monitor (PerfMon) has been around for several generations of Windows and allows you to monitor, either over time or in real-time, the performance statistics of a Windows server.
Performance Monitor can capture a plethora of information on a Windows Server and is useful in diagnosing performance problems. However, to meaningfully analyze the PerfMon data captured when troubleshooting performance issues, it is critical that you have a baseline of normal system performance for comparison. This article focuses on using PerfMon to create a performance baseline on a Windows Terminal Server, but the following information also applies to baselining any Windows-based server.
Using Performance Monitor, performance data can be captured in a variety of granularity, from total processor utilization on a server down to the processor time used by an individual Windows process. However, to understand how to obtain the information you want, it is important to understand the three fundamental levels of monitoring criteria. These three levels are detailed below:
Objects: Objects are the top-most criteria for monitoring a set of attributes on the server. Typical objects include Memory, Network, Paging File, Processor, etc.
Counters: Counters are a subset of an object. For any given object, you will have multiple counters. For example, the Processor object has various counters to choose from: % processor time, % privileged time, % user time, interrupts/second, etc.
Instances: Each counter can have one or more instances. Using the example above of the processor object, % processor time would have two instances in a dual-processor system – one for each processor (0 and 1). You have the ability to monitor only one instance of a given counter if you wish.
Another way to look at this relationship is as follows (figure 1):
Figure 1
You can select the object itself, which includes all counters and all instances of each counter, a specific counter for an object, which includes all instances for that counter, or you can select only to view/track a specific instance of a given counter (for example, instance 0 of the % Processor Time counter of the Processor object).
Using Performance Monitor
The default screen shows current activity on the system, measuring pages/sec, average disk queue length and processor utilization.
-
To baseline a system, select Counter Logs under Performance Logs and Alerts. By default, there is a basic counter log that measures the same three counters as listed above. Although you can’t delete the sample, you can create your own custom counter log.
-
Right click on Counter Logs and select New Log Settings… The New Log Settings screen comes up and prompts you to name the job. As a good rule of thumb, it is best to make the job name as descriptive as possible to make future references easier. Include things like the server name and the date that the baseline is being taken.
Enter the job name and click OK. -
Now it’s time to set up the counters. You will notice that there are two buttons available – Add Objects and Add Counters. Most of the time, you will find that adding entire objects will result in too much data being collected. For a proper baseline, you only need to capture the basic information about the performance of a server. Granular items (such as Processor\Pool Paged Bytes) will have no bearing on the baseline, so it’s overkill. Also, with each additional counter added, the server has to use resources to track that performance data. Adding too many counters by selecting entire objects can easily put undue strain on a server and skew your baseline results. Therefore, it’s best to only add the counters you wish to track.
Clicking Add Counters… button will bring up the following screen (figure 2)
Figure 2
By selecting a performance object from the drop-down list, you can drill down to specific counters and instances of that object.
Below is a list of object counters that make up a good, well-rounded baseline. You should include all instances of each counter except for the Network counters; they should only monitor the instances for the NICs that will be included in the baseline (if appropriate). The details on what each counter gathers will be discussed in part 2 of this article.
Memory
-
Pages/Sec
-
Available Mbytes
-
Committed Bytes
-
Page Faults/Sec
Network Interface
- Bytes Total/Sec
- Packets/Sec
Paging File
- % Usage
Physical Disk
- % Disk Time
- Avg Disk Bytes/Transfer
- Avg Disk Queue Length
- Avg Disk Sec/Transfer
- Disk Transfers/Sec
Processor
-
% Processor Time
-
% Privilege Time
-
% User Time
-
Interrupts/Sec
System
-
Context Switches/Sec
-
Processes
-
Processor Queue Length
The following counters are for Terminal Servers specifically, and will aid in translating the output into meaningful information:
Terminal Services
-
Active Sessions
-
Total Sessions
Terminal Services Session
-
% Processor Time
-
Page Faults/Sec
-
Once you have added any appropriate counters, you can select the sample interval. The default setting of 15 seconds is usually sufficient, but if the server is utilized rather heavily, then set the sampling interval to 30 seconds or more to cut down on the impact that performance monitor may have on normal running conditions.
To set the interval, on the General Tab (figure 3), set the Sample data every: parameter to the desired setting, and the corresponding Units (in seconds, by default).
Figure 3
- On the Log Files tab (figure 4), you can change the type of log file and where they are stored.
Figure 4
Typically, a binary log file is sufficient if you will be reviewing the data in PerfMon (typical). However you have the option of using a delimited text file (however, delimited files cannot be read by PerfMon) or even streaming the data to an SQL database. For the purposes of this article, we will stick to a binary file.
Clicking on the Configure… button will allow you to set both the file name prefix (which defaults to the job name) and the location of the files. You can also set a maximum size for your log files to prevent them from growing too large. The default of “Maximum limit” will allow the log file to continue to grow until it consumes all space on the drive, so it might be a good idea to set a maximum file size to prevent this if drive space is short or you will not be setting an end time/date for the job on the Schedule tab. Once the log file reaches the specified size, PerfMon will stop logging information.
Another option, however, is to use a Binary Circular File for the log file. Once the log file grows to the size specified, PerfMon will begin flushing the oldest information in the log file to make room for the new data. This will ensure you always have the latest performance statistics when you stop the log, and the log file will never grow beyond the specified size.
-
Finally, the Schedule tab (figure 5) allows you to decide whether the PerfMon job will start and stop at specified times or will require manual intervention. For baselining, you would typically set a start and stop time/date. It is always good to set a stop time if you don’t set a maximum log file size. This will prevent the logs from accidentally filling the drive if you forget to turn off PerfMon. In this example below, Perfmon is set to log data for seven days.
Figure 5
-
All that is left is to start collecting data. To manually start the job, right click the job name in the Counter Logs screen and select Start. Otherwise, the job will start automatically when the scheduled time arrives.
Note: No one needs to be logged on to the server for data collection. PerfMon will automatically start and stop jobs without a user being logged on.
Once the job is started, its icon will turn green
With the job now running, the PerfMon is collecting data. The best way to get the most reliable data is to run the server in production as usual. The idea is to allow Performance Monitor to capture performance statistics as the server is under normal use. This will provide a good baseline for future comparison.
Part 2 of this article will go into depth on how to interpret the data gathered and how to effectively use a baseline to troubleshoot future issue.
If you would like to read the next article in this series please go to Using Windows Performance Monitor to Baseline a Terminal Server (Part 1).
