With the Performance Console, you can measure the
activity of any computer on the network. System Monitor and the
Performance Logs And Alerts snap-ins are built in as parts of the
Performance console (perfmon.msc). The System Monitor snap-in allows for
the viewing of real-time performance data as collected from
configurable counters. The Performance Logs And Alerts snap-in allows
for the recording of performance data (logs) and configurable actions
when a threshold for a counter is breached (alerts). The Performance
console allows you to perform multiple tasks, including the following:
Collect and view real-time performance data View data collected in a log Present data in a graph, histogram, or report view Create HTML pages from views by importing of log file settings Save monitoring configurations that can be loaded into System Monitor on other computers
Configuring System Monitor
With System Monitor, you
can collect and view data by configuring counters that report hardware,
application, and service activity for any computer on your network.
Three configurations must be made for the data you wish to collect.
Type of data You can specify one or more counter instances of performance monitor objects for which you want data to be reported. Source of data
Either local or remote computer data can be collected by a counter. You
must be a local administrator or a member of the Performance Log Users
group on the computer from which you wish to collect data. Sampling intervals Data can be recorded manually in real time, or set to a periodic interval that you specify.
Viewing Data
When you first open System Monitor, three counters are loaded and begin to report real-time data:
Figure 1 shows the System Monitor with the default counters loaded.
Additional counters can
be added or removed by choosing Add (Ctrl+I) on the toolbar, or
right-clicking anywhere in the details pane and choosing Add Counters
from the shortcut menu. In the Add Counters dialog box, you can select
any of the available counters for either the local computer or any
remote computer on your network. Counters are arranged and available for
use based on the type of object, the counter in the object category,
and the instance of the counter.
Object A logical collection of resource, service, or application counters. Counter A data-reporting item. The data reported depends on the type of counter. Instance
Refers to one or more occurrences of a counter, indexed by the number
available on the computer. For example, on a computer with two
processors, Instance “0” would refer to the first processor, Instance
“1” to the second, and “_Total” the aggregate of both instances. In the
case of a single instance of a counter, Instance “0” and “_Total” will
be available.
Figure 2 shows the %Processor Time counter for Server01, which is a single-processor computer.
Exam Tip Remember that “_Total” represents the combined data from multiple instances of a counter when multiple instances are available. |
Logging and Alerts
With Performance
Logs And Alerts, you can collect performance data automatically from
local or remote computers. You can view logged counter data by using
System Monitor, or you can export the data to spreadsheet programs or
databases for analysis and report generation. You can configure any
counters available within System Monitor for use in Performance Logs And
Alerts, with the following options:
Collect data in a CSV or tab-separated format for exporting. View Counter Log data during logging and post-collection. Set Trace Logs (event-driven) based on available providers. Define parameters for the log file including start and stop times and maximum file size. Set
an alert on a counter with options to send an administrative message,
an application is executed, or a log is started when the configured
threshold on the counter is breached.
Figure 3 shows the configuration dialog box for an alert on Server01 when Free Disk Space drops below 20 percent.
When
monitoring performance data for your server or network, start from the
top down; that is, start with the broadest monitoring configurations of %
Processor Time, Disk and Processor Queue Length, Memory Use, and
Network I/O to determine where the bottleneck occurs. Once you have
determined the problem area, then look at the particular services and
applications using the resource, and at protocol and thread levels, if
needed. Usually, there is either one device or application causing the
problem, or a global lack of resources on the system. Single devices can
be reconfigured or replaced, and global resources can be added (more
memory, faster processor, and so on) as appropriate. The
results of this monitoring can be ambiguous; however, if you do not
have a baseline of system performance by which to judge your monitoring
results. As soon as is practical after configuring a new computer,
perform a set of monitoring activities for the key Processor, Memory,
Network, and Process (Application and Services) objects to determine how
your computer performs under normal conditions—commonly called a baseline—in
normal, idle, and peak performance states. When problems or bottlenecks
occur during later monitoring, measurement against the baseline will
help to find a solution. |
|
Decisions About Objects and Counters
The
object counters that you choose in monitoring a server, either for a
baseline or ongoing performance evaluation, can be considered in one of
two ways. One method of server monitoring examines the role that the
server performs in the environment and the corresponding demands placed
on that server by the user population. Another view of server monitoring
involves examining object categories of counters such as Processor,
Memory, Network Interface, and PhysicalDisk, with less emphasis on the
role that the server fulfills and more on a consistent monitoring
standard.
Server Roles
Monitoring by
server role is useful when servers perform within a single role in the
network environment. These roles are defined by the services or
resources that the server provides to the users. Examples of server
roles include domain controllers, file servers, and Web servers. A
server’s demand for resources can be matched, in a performance
monitoring situation, with the appropriate object counters that measure
the resources most heavily used by a server in that role. Ongoing
performance monitoring data can be compared to baseline data for
optimization within that role. Table 1 outlines the objects that are commonly used when analyzing a server by its role.
Table 1. Server Roles and Objects To Be Monitored| Server role | Resources used | Objects and counters |
|---|
| Application servers | Memory, network, and processor cache | Memory, Processor, Network Interface, and System | | Backup servers | Processor and network | System, Server, Processor, and Network Interface | | Database servers | Disks, network, and processor | PhysicalDisk, LogicalDisk, Processor, Network Interface, and System | | Domain controllers | Memory, processor, network, and disk | Memory,
Processor, System, Network Interface, protocol objects
(network-dependent, but can include TCPv4, UDPv4, ICMP, IPv4, NBT
Connection, NWLink IPX, NWLink NetBIOS, and NWLink SPX), PhysicalDisk,
and LogicalDisk | | File and print servers | Memory, disk, and network components | Memory, Network Interface, PhysicalDisk, LogicalDisk, and Print Queue | | Mail/messaging servers | Processor, disk, network, and memory | Memory, Cache, Processor, System, PhysicalDisk, Network Interface, and LogicalDisk | | Web servers | Disk, cache, and network components | Cache, Network Interface, PhysicalDisk, and LogicalDisk |
For
each server role, create a baseline using the counters within each
object appropriate for the role, and periodically examine each of the
servers for significant changes.
Object Categories
In a network
environment where servers perform within multiple roles, role-based
monitoring can leave important gaps in monitored data. In such cases,
more complete data should be collected from each of the primary object
categories.
Memory Counters
After you have
established a baseline for memory use, periodic monitoring should be
performed for deviations from that baseline. The following counters are
useful in monitoring computer system memory:
Memory
shortages: Memory\Available Bytes, Available Kbytes, or Available
MBytes (to see the amount in megabytes); Process (All_processes)\Working
Set; Memory\Pages/sec; Memory\Cache Bytes. These counters show how much memory is taken up by all processes, and how much memory is available. Frequent
hard page faults: Memory\Pages/sec; Process (All_processes) \Working
Set; Memory\Pages Input/sec; Memory\Pages Output /sec.
Hard page faults occur when a page of memory is needed but has been
placed (swapped) into virtual memory. Excessive swapping degrades the
performance of the computer, and can be addressed either by reducing the
demands on the computer or increasing the amount of physical RAM.
Network Counters
Network
counters report data from the network interface cards (NICs) installed
in the computer, and from the segment on which the NICs communicate. The
following counters are useful in measuring the performance of a
computer on the network:
Network Interface\Output Queue Length; Bytes Total\sec.
The Queue length should be low, and the total bytes high, which
indicates a network card that is transferring packets quickly and
without delay. Network Interface: Bytes Sent/Sec; Current Bandwidth; Bytes Received/Sec.
High values in these counters consistently and over time indicate that a
network is being expected to carry more traffic than is optimal.
Segmenting the network into smaller pieces or increasing the bandwidth
of the network will decrease the chances of bottlenecks due to excessive
traffic.
Note Different
types of network configurations will allow for various levels of
traffic efficiency and volume. When monitoring %Network Utilization, for
example, 30 percent utilization is the maximum recommended for an
unswitched Ethernet network. This means that a 10 megabyte (MB) Ethernet
network becomes bottlenecked when its throughput exceeds 3 MB per
second. If the value of the counter is above 40 percent, data collisions
begin to hamper the performance of the network. |
Process Counters
For
each demand on a system resource, there is often a process that is the
instrument of that demand. Using process counters allows for viewing the
individual processes (including system services) that are using system
resources. The following are important counters to use when gathering
process-based performance data:
Memory
leaks; memory-intensive applications: Memory\Pool Nonpaged Allocs;
Memory\Pool Nonpaged Bytes; Memory\Pool Paged Bytes;
Process(process_name)\Pool Nonpaged Bytes; Process(process_name)\ Handle
Count; Process(process_name)\Pool Paged Bytes;
Process(process_name)\Virtual Bytes; Process(process_name)\Private
Bytes. These counters show memory use by
individual processes, allowing for redistribution of intensive
applications (or isolation of applications with memory leaks) to other
computers.
Note An
application memory leak can be diagnosed by running that application on
its own server, and monitoring for memory use that increases over time
with no change in demand for services. This increase without a
corresponding reason can indicate a memory leak. |
Disk Counters
The PhysicalDisk
object counters provide data on activity for each of the hard disk
storage devices, and the LogicalDisk object counters provide data on
defined volumes (C:\, D:\, and so on) in your system. Monitoring
LogicalDisk free space and PhysicalDisk performance counters will
provide useful data. The following are important counters for Physical
and Logical Disk monitoring:
LogicalDisk\%Free Space.
This counter reports the percentage of unallocated disk space to the
total usable space on the logical volume. This counter is not available
for a physical disk. Note When calculating the _Total instance, the %Free Space counters recalculate the sum as a percentage for each disk. |
PhysicalDisk\Avg. Disk Bytes/Transfer; \Avg. Disk sec/Transfer; \Avg. Disk Queue Length; \% Disk Time.
These counters measure the size of input/output (I/O) operations over
time, and how busy the drive is, performing the requested disk activity.
The disk is efficient if it transfers large amounts of data relatively
quickly, and has a queue length <2 over time for each disk spindle.
Practice: Using the Performance Console
In
this practice, you will record Performance data, analyze the data in
System Monitor, and export the data for import into an Excel
spreadsheet.
Exercise 1: Recording Performance Data
In this exercise, you will create a log file with LogicalDisk, PhysicalDisk, and Server Work Queue data.
1. | Log on to Server01 as an administrator, and start the Performance console.
| 2. | Expand Performance Logs And Alerts in the folder pane, and then select Counter Logs.
| 3. | In the detail pane, right-click and select New Log Settings from the shortcut menu.
| 4. | Create
a log file called Test, and add the LogicalDisk, PhysicalDisk, and
Server Work Queues objects to the log, and set the data sampling
interval to 8 seconds. Take note of the file name and location for the
log, and then click OK to start the log.
| 5. | As
the log is recording, perform some activities with other applications
on your computer. After approximately 30 seconds, return to Performance
Logs And Alerts and stop the log recording.
| 6. | In System Monitor, click View Log Data (Ctrl+L, or fourth button from the left), and load the log file from your test.
|
The graph in System
Monitor now shows the recorded data from your logging session. You can
now change the views between graph, histogram, and report to see the
data in different ways. This log file that you have created is in the
default format (Binary File), strictly for use in the Performance
Console.
Exercise 2: Importing Logged Data
In this exercise, you will save the logged data from Exercise 1 for import into Microsoft Excel.
1. | If needed, reopen the Performance console.
| 2. | Right-click the Test log file setting, and then choose Properties.
| 3. | In
the Test Properties dialog box, click the Log Files tab, and then
change the Log File Type from Binary File to Text File (Comma
Delimited).
| 4. | Click
OK, and then start the log file recording. Perform some disk-related
tasks on your computer for approximately 30 seconds, and then stop the
log recording.
|
The log file you have created is in CSV format, and can be opened, viewed and analyzed in Excel.
Note If
you intend to load the CSV file into Excel, Performance Logs And Alerts
cannot have the file open because Excel requires exclusive access to
the file to open it. |
|
